a

altavir

03/08/2021, 9:24 AM
@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

03/08/2021, 9:35 AM
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.
a

altavir

03/08/2021, 9:37 AM
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

03/08/2021, 9:41 AM
oh, that's a fairly easy question, then: any space over a field with characteristic 2 cannot have division by 2.
a

altavir

03/08/2021, 9:41 AM
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

03/08/2021, 9:42 AM
any space will naturally have multiplication with integers (because it can be expressed through addition and subtraction), but not necessarily with other numbers.
a

altavir

03/08/2021, 9:43 AM
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

03/08/2021, 9:47 AM
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?
a

altavir

03/08/2021, 9:50 AM
We have ExponentialOperations inteface which defines exponential. We can create sinh from it, but for this we also need division by number.
р

Ролан

03/08/2021, 10:34 AM
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
a

altavir

03/08/2021, 10:42 AM
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.
р

Ролан

03/08/2021, 10:42 AM
So which library are we using that does not come with sinh?
a

altavir

03/08/2021, 10:43 AM
Kmath core 🙂
and a lot of contexts there.
р

Ролан

03/08/2021, 10:44 AM
Yeah but that's our implemetation; of course we have to provide everything
a

altavir

03/08/2021, 10:44 AM
Let me see if we have any actual cases for that other than sinh and averaging. It not, it does not worth supporting.
р

Ролан

03/08/2021, 10:55 AM
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. `sum`is defined over a ring, but avg is not
a

altavir

03/08/2021, 11:03 AM
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
р

Ролан

03/08/2021, 12:39 PM
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

03/08/2021, 12:45 PM
a generic algebra wouldn't even have exponentiation, so division is not a core issue here.
р

Ролан

03/08/2021, 12:46 PM
it is an element wise exp
the point is that it is over a field
a

altavir

03/08/2021, 12:47 PM
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
р

Ролан

03/08/2021, 12:47 PM
OK I think it is too much of math terminology
a

altavir

03/08/2021, 12:48 PM
As I already said, keeping strict algebraic therminology is not the aim (we still want to use it whereever it is possible)
р

Ролан

03/08/2021, 12:48 PM
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
a

altavir

03/08/2021, 12:50 PM
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

03/08/2021, 12:52 PM
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.
a

altavir

03/08/2021, 12:54 PM
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.
4 Views