<@U0BA5R9KL> My current study shows that with cont...

# mathematics

[altavir]

@breandan My current study shows that with context approach, we can get all abstractions free (in performance) because everything is resolved statically. The only question is boxing and it seems like I found a way around it. For now it works only on JVM, because I need ByteBuffer for it, but with development of kotlinx-io, we can move it to other platforms as well.

[breandan]

Interesting. I'll take a closer look at kmath, looks like it's heading in the right direction. I've been looking for a good JVM tensor math library, and there are a few implementations out there (e.g. https://deeplearning4j.org/docs/latest/nd4j-overview https://github.com/idsc-frazzoli/tensor), but I've been wondering if it's possible to build something in Kotlin for while and what additional features a Kotlin-native library could offer.

[altavir]

I am not sure it is good yet. Performance on basic operations is OK, but my pythonic students are not happy with the feature set. So I need some input about the direction of next steps. Also linear algebra currently is almost non-existent.

[altavir]

Because I actually do not use it, regular geometry is more important for me.

[breandan]

Not necessarily looking for stability, but a more principled approach in terms of type safety. I'm interested in applying it to automatic differentiation and would like to avoid writing a bunch of messy code to translate from mathematical notation to numerical types. This is my side project: https://github.com/breandan/kotlingrad

[breandan]

I'm working on some algebraic abstractions for numerical types, but really this should be a separate project altogether: https://github.com/breandan/kotlingrad/tree/master/src/main/kotlin/co/ndan/kotlingrad/math/algebra

[altavir]

It seems I've already done that in the previous version (before kmath, inside larger project). As for kmath it features expression building exactly for that purpose. You can see it here: https://github.com/altavir/kmath/blob/dev/kmath-core/src/commonMain/kotlin/scientifik/kmath/expressions/Expression.kt

[altavir]

And tests are here: https://github.com/altavir/kmath/blob/dev/kmath-core/src/commonTest/kotlin/scientifik/kmath/expressions/FieldExpressionContextTest.kt

[altavir]

For automatic differentiation we need only to build alternative ExpressionContext

[breandan]

Interesting! It looks very close to my use case. I've been using property testing from KotlinTest

[breandan]

These are my tests: https://github.com/breandan/kotlingrad/blob/master/src/test/kotlin/co/ndan/kotlingrad/calculus/TestFiniteDifferences.kt

[altavir]

We currently have people to develop it, but I need further insight in what people actually need and feature requests. I also would be very happy for any contributions. It is obvious that mathematic library should be developed by community, not single person.

[altavir]

By the way, current Kmath structure in theory allows some more complicated things like AD in complex numbers or even ND-structures (everything that forms a Field or ExtendedField if we need trigonometry etc)

[breandan]

Agreed, I don't have enough resources to do it properly, but maybe if we pooled our resources on kmath... I'll think of some use cases and get back to you.

Yeah, this is interesting. I like the idea of abstracting over different number systems. I think if done properly, you could provide an embedded DSL for symbolic representation of mathematical expressions, where numerical types like `Double`/`Float`/`Int` were just instances of a generic type.

[altavir]

Indeed. We need more performance tests, but for now optimized things work faster than in python (single-core).

[altavir]

I mean numpy of course