https://kotlinlang.org logo
Join Slack
Powered by
<@UR2B5DTTL> A question about algebras. Could you ...
# mathematics
a
@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
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
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
oh, that's a fairly easy question, then: any space over a field with characteristic 2 cannot have division by 2.
a
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
any space will naturally have multiplication with integers (because it can be expressed through addition and subtraction), but not necessarily with other numbers.
a
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
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
We have ExponentialOperations inteface which defines exponential. We can create sinh from it, but for this we also need division by number.
р
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
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.
р
So which library are we using that does not come with sinh?
a
Kmath core 🙂
and a lot of contexts there.
р
Yeah but that's our implemetation; of course we have to provide everything
a
Let me see if we have any actual cases for that other than sinh and averaging. It not, it does not worth supporting.
р
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
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
р
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
a generic algebra wouldn't even have exponentiation, so division is not a core issue here.
р
it is an element wise exp
the point is that it is over a field
a
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
р
OK I think it is too much of math terminology
a
As I already said, keeping strict algebraic therminology is not the aim (we still want to use it whereever it is possible)
р
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
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
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
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
Open in Slack
PreviousNext
Powered by