altavir

    altavir

    1 year ago
    @Aleksei Dievskii A question about algebras. Could you give an example of a
    Space
    which does not have a numeric scaling of its members? We have some problems bringing KMath inheritance model in check and keep it practical so I am thinkgin about different architectural approaches.
    a

    Aleksei Dievskii

    1 year ago
    I'm not sure I understand the question. any (linear) space has multiplication with a scalar by definition. if the underlying field is not numeric then we could say that the scaling is not numeric too.
    altavir

    altavir

    1 year ago
    The problem is that we seem to have two different types of scalars. For example for NDStructure<T> we have a T scalar and Number scalar and they are conflicting. Current idea is to remove Numbers, but it brings some problems like how to write a generic hyperbolic sine ( need to divide by a scalar 2.0)
    cc @Ролан
    a

    Aleksei Dievskii

    1 year ago
    oh, that's a fairly easy question, then: any space over a field with characteristic 2 cannot have division by 2.
    altavir

    altavir

    1 year ago
    I am currently inclined to go with algebraic definition and remove numeric operations from core classes, but it could impact usability and add code dublication in final classes
    a

    Aleksei Dievskii

    1 year ago
    any space will naturally have multiplication with integers (because it can be expressed through addition and subtraction), but not necessarily with other numbers.
    altavir

    altavir

    1 year ago
    Multiplication by integer is mostly useless.
    The problem with Kotlin right now (and cc @elizarov here) is that I can add all those operations as extensions, but I can't do that for
    times
    since I have only one reciever. So If I remove
    NDStructure<T>.times(num: Number)
    I won't br able to use it. Not a bit loss probably, but it can impact usability.
    a

    Aleksei Dievskii

    1 year ago
    well, you can have the operation throw if it's not applicable to the current space.
    @altavir what is a "generic hyperbolic sine", by the way?
    altavir

    altavir

    1 year ago
    We have ExponentialOperations inteface which defines exponential. We can create sinh from it, but for this we also need division by number.
    Ролан

    Ролан

    1 year ago
    You can have algebras over a ring (tensors over integers), but also over a field (tensors over doubles), and some of them are division algebras (or not quite but cc the discussion on the hadamard product)
    I think operations involving the Number type are bad. First of all it is unclear what the user wants: does he want he data in the tensor to be mapped to the one in the Number or he wants the Number to be casted to T, but then why does not he simply enforce the casting himself?
    @altavir things like sinh must be left to the implementation - it is a bad idea to cook it yourself from exp in the interface
    Various libraries will provide optimised version for those functions
    altavir

    altavir

    1 year ago
    If we leave it to implementation, we will have a lot of code duplication. You can always override it in the implementation if it is based on the external library.
    Ролан

    Ролан

    1 year ago
    So which library are we using that does not come with sinh?
    altavir

    altavir

    1 year ago
    Kmath core 🙂
    and a lot of contexts there.
    Ролан

    Ролан

    1 year ago
    Yeah but that's our implemetation; of course we have to provide everything
    altavir

    altavir

    1 year ago
    Let me see if we have any actual cases for that other than sinh and averaging. It not, it does not worth supporting.
    Ролан

    Ролан

    1 year ago
    I am not sure I understand unfortunetaly what the problem with code duplication is? Normally you have to make a difference between Algebras over a ring and those over a field.
    And that should work fine. sumis defined over a ring, but avg is not
    altavir

    altavir

    1 year ago
    It is simple. Say, you have RealNDField and ComplexNDField. Both of them have exponential operations.
    sinh is not a problem though because you can do it with extensions
    Ролан

    Ролан

    1 year ago
    So it should be RealNDAlgebra and not field, cc @Aleksei Dievskii, and it should derive from something like AlgebraOverField for interface (containing exp, avg etc.) . AlgebraOverField should derive from AlgebraOverRing which for example has sum
    We need to alarm those who write extensions that we expect them to implement sinh. If you want to provide custom implementation then create DefaultAlgebraOverField and implement anything you want there, @altavir
    Those libraries which cannot implement some of the methods would have to explicitly derive from DefaultAlgebraOverField and therefore it will be clear to the client that some of the methods have poor perfomance for that given extension
    a

    Aleksei Dievskii

    1 year ago
    a generic algebra wouldn't even have exponentiation, so division is not a core issue here.
    Ролан

    Ролан

    1 year ago
    it is an element wise exp
    the point is that it is over a field
    altavir

    altavir

    1 year ago
    We can't make it too comlicated. I will think a little bit more about hyperbolic functions since they are the only remaining problem. For now, I am keeping the core hierarchy but removing numeric operations. It could inconvenience expression, but we do not use them a lot anyway
    Ролан

    Ролан

    1 year ago
    OK I think it is too much of math terminology
    altavir

    altavir

    1 year ago
    As I already said, keeping strict algebraic therminology is not the aim (we still want to use it whereever it is possible)
    Ролан

    Ролан

    1 year ago
    in that case it makes sense, I already use it for tensors
    Being over a field or over a ring is an important distinction at the computational and API levels as well. Most autograd engines work only over fields
    altavir

    altavir

    1 year ago
    Indeed, but we do not have problems with that. There are some problems with special functions like
    exp
    since kotlin does not have type-intersections. But everything works so far.
    More importantly, MST allows to do autograd on a symbolic level.
    a

    Aleksei Dievskii

    1 year ago
    if we limit ourselves to algebrae with fixed basis (since this is the only way to define element-wise operations) over exponential fields of characteristic 0, then everything should work.
    with a small caveat: a field of characteristic 0 won't necessarily allow multiplication by an arbitrary real number, but all the Numbers in JVM are actually rational. so we can define
    times(Number)
    for any such algebra.
    altavir

    altavir

    1 year ago
    The problem comes only when we want to propagate functions. For example, if we want exponential operations on ND or Expressions, we need a type for exponential operation. The same for trigonometric operations, the same for norm, etc. Since we do not have for type intersections, we need to create combination of types to propagete and in general it leads to a combinatoric explosion. Luckily for us, we have only limited number of generic element-types.
    Multiple receivers would deffinitely help here. But context -based dispatch makes it possible even now.