<@U02S5GRD449> I've started to do a review on your...

# mathematics

[altavir]

@Gleb Minaev I've started to do a review on your PR. It is too large to be in functions module (it is intended to be lightweight). Could you create a separate module like kmath-rational and move all but basic polynomials there?

[altavir]

And I probably do not understand most of functionality. For example what is a "Numbered polinomial". If it is just a multivariate polynomial, why not typealias MultivariatePolynomial = Map<Symbol, Plynomial>? It would completely solve all structure problems. And then mulitvariate polynomial is easily constructed on top of regular polynomial algebra.

[Gleb Minaev]

1. "Numbered polynomial" is a way to represent polynomials with numbered variables (e.g. Int instead of Symbol is used to identify variables). More precily, let there be polynomial 3 + 5 y - 7 x^2 z. Obviously, we should represent it as a map from variables powers sets of its monomials to coefficients of corresponding monomials (like {() -> 3, (y) -> 5, (x^2 z) -> -7}). So now the question is how we should represent such variables powers set of each monomial (let's call it "signature" of the monomial). If you have representation of variable as `Symbol`s then signatures can be represented as a `Map<Symbol, UInt>`: now 3 + 5 y - 7 x^2 z is {{} -> 3, {y -> 1u} -> 5, {x -> 2u, z -> 1u} -> -7}. That's how "labeled polynomials" work. But if you have representation of variablese as `Int`s (if you numbered your variables) then signatures can be represented as lists of powers where value on each index i is power of `i`th varible: if x, y, and z are numbered as 0, 1, and 2 then 3 + 5 y - 7 x^2 z can be represented as {[] -> 3, [0u, 1u] ->5, [2u, 0u, 1u] -> -7}.
2. Sorry, I don't understand how you suggest to represent multivariate polynomial as a map from variables to univariate polynomials (for example, still the same 3 + 5 y - 7 x^2 z).

[altavir]

Ah, OK, I forgot that mixed terms are also possible. Still, there should be some kind of more intuitive structure for those. Also using indices is a bad idea, since symbol resolution is pretty fast and we can always optimize inner logic by caching symbols with SymbolIndexer

[altavir]

We can organize a seminar and discuss the API

[Gleb Minaev]

Yeah, I think it will be great to discuss the API in any format. Seminar is nice.

[Gleb Minaev]

There is also possible sugestion to implement different domain-specific implementations of multivariate polynomials. For example, if you are calculating dth Taylor polynomial for some very random function of x_1, ..., x_n then most probably you will need all monomials x_1^{d_1} ... x_n^{d_n} for all 0 <= d_i <= d. If you are working with projective geometry you need only homogenous polynomials, i.e. d_1 + ... + d_n = d. In first case multidimensional array-like structure will be better. In second case I am not sure but it seems like that too (but with some tricks). But in very very general case map-like structure should be better.

[altavir]

Map-like is OK. But right now it is not intuitive how to use those. Maybe better builders are in order. Or Term requires an additional wrapper structure or typealias to describe it.

[altavir]

Anyway, moving everything into a separate module is the first task. We can mark it as prototype and use less strict rules for backward compatibility.

[Gleb Minaev]

Sorry for the delay. I moved everything except everything list- to new module kmath-polynomialX. Although, it seems there are some issues after the move. Now I am trying to resolve them as much as I can and move rest parts to the new module.

[altavir]

polinomils will be fine. We do not have other modules with polinomials

[Gleb Minaev]

I fully seperated the former module and the prototype. Should I move the prototype to another branch leaving only minimal changes (like implementation of polynomial multiplication, etc.) to review?