@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.

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.

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)

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

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

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

Multiplication by integer is mostly useless.

well, you can have the operation throw if it's not applicable to the current space.

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)

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?

Kmath core 🙂

Yeah but that's our implemetation; of course we have to provide everything

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.

It is simple. Say, you have RealNDField and ComplexNDField. Both of them have exponential operations.

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

a generic algebra wouldn't even have exponentiation, so division is not a core issue here.

it is an element wise exp

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

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

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.

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.

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.