Just ran into a complex number problem by taking the cubed root of a negative number

(-4.0).pow(1.0/3.0)

, which returns

NaN

due to lack of support for imaginary numbers. However, Java has

Math.cbrt()

specifically for this purpose. Is this something Kotlin should explicitly support?

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

@altavir @kyonifer resuming conversation from #datascience, I think we need to be clear what we are trying to achieve, other than "make it not NumPy". Are we trying to create a better backend engine? Or trying to establish interfaces and idioms? The nice thing at Kotlin is you can easily make things idiomatic and add syntactic sugar on top of an ugly base implementation. I made some small contributions to Koma aligned to that philosophy. I think it's also important to consider we want to not only avoid Python style, but also Java. Personally I think interfaces should never have to be used in application usage. There should be extension functions like toMatrix() to turn iterables of items into matrices, use matrixOf() varargs functions, etc.

Have any of you ever looked at source code for ojAlgo? I think Anders did some pretty interesting approaches in both the implementation and external API, and trying to keep it up-to-date with modern Java idioms. It's therefore a complete contrast of approach to NumPy. Since it's pure Java, part of me wishes to port it to Kotlin just to see how it would turn out. https://github.com/optimatika/ojAlgo

Interesting paper on computer algebra in Java and Scala: https://pdfs.semanticscholar.org/c006/b5853ecde7f4fd220c6e1a252ad73baa6b5b.pdf There is a pretty sophisticated CAS written in Java: https://github.com/kredel/java-algebra-system Some benchmarks: https://core.ac.uk/download/pdf/82543770.pdf I think the discussion about NumPy/SciPy et al. versus a native statically-typed library falls into the broader discussion of scripting vs. computer algebra systems. They serve different goals, but it's possible to have essentially the same notation with operator overloading and type inference. The question is how much abstraction is too much and how much flexibility are you willing to sacrifice to get type safety? I suspect you want people to be able to extend these APIs without knowing abstract algebra and category theory. @altavir @thomasnield @kyonifer

I suspect you want people to be able to extend these APIs without knowing abstract algebra and category theory.

No, I definitely do not want people to extend any classes if they do not want what they are doing. This is a Java approach and we want to move away from it. I want people to use existing constructs and possibly write extension functions.

I've finished editing article on context-oriented programming basics: https://medium.com/@altavir/an-introduction-context-oriented-programming-in-kotlin-2e79d316b0a2. My current interest in this is mathematics so I am posting it here.

Here is an interesting proposal about primitive specialization: https://discuss.kotlinlang.org/t/primitive-type-specialization/11022

What characters valid Kotlin identifiers? Some unicode characters are allowed without backtick-escaping. For example

val ε = 0.03

is a valid statement, but

val ∇ = 0.03

is not.

@altavir Have you considered using sealed classes / algebraic data types (ADTs) for expressions? The original use case exactly fits building abstract syntax trees of symbolic elements, for example: https://kotlinlang.org/docs/reference/sealed-classes.html https://antonioleiva.com/sealed-classes-kotlin/ See also the original paper on GADTs: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/gadtoop.pdf

Also class structure seems a little bit overengeneered. It is completely opaque to the user so it is not the problem, but still I am not completely happy with it.

From user point of view everything will be simplified down to factory methods. What I really fear is too complicated type structure for developers. For example, ojalgo is super complicated, I am not sure anyone but the author can understand what happens inside.

Do someone know a good way for matrix inversion benchmarking? The problem is that obviously inversion will have different complexity for different matrices, and I can't use random ones because not every matrix could be inverted. To generate them as LUD?

@altavir I'm stealing your idea of context oriented programming for Kotlin𝛁. It's nice because you can declare extensions on parametric types, for example declaring

fun List<TypeA>.doSomething() = Something()

and

fun List<TypeB>.doSomething() = SomethingElse()

in the same scope for multiple dispatch on a generic type. What's interesting is that this behavior is not possible to implement with a true member function inside

List

(due to type erasure), but since the call site knows the type then it will work! This is very cool! https://github.com/breandan/kotlingrad#how

@altavir what's your barrier in keeping it going?

@altavir what are the big disadvantages of JNI anyway? Besides debugging inconvenience and weird overheads outside the JVM? 🤔 the more I watch you toil at this and deal with boxing the more I wonder if we truly are making this BLAS thing difficult.

Are we really doing this for the sake of doing it the Kotlin way? What would happen if you made the implementation just in Kotlin Native and you did JNI bindings for the Java interface? Would getting off the JVM free your performance constraints? From your Graal experiences it sounds like that would be the case

I've recently ported a small (~5kLOC) signal processing algorithm I wrote against koma to both julia and swift. I also wrote my own

Matrix

implementation in both of those languages just to make sure it wasn't some weird optimization done by the builtin libs that was cheating. My matrix wrapper used builtin arrays with the matrix algorithms i needed added in by me: on julia implemented using multiple dispatch, on swift using their generic specialization of protocols to eliminate virtual calls and protocol/value witness table lookups. In both cases i ended up with something that was fast, no codegen required, and generic. It was a discouraging result, because i prefer the language of kotlin much more but i have spent much more time trying to make it fast (via koma) than my weekend project in those two

I've also become nervous recently that implementing high performance numerical libraries in a user-friendly OO language will require a technique available to eliminate virtual function call overhead outside of just the JIT. For this I have no evidence yet (I haven't done the fine-grained benching required to separate out delay sources, which can be quite tricky when doing cross language benching of JIT-ed languages), but it is something that chris lattner called out specifically when talking about using the jvm/java for tensorflow ("it is possible that our approaches could work for this class of languages, but such a system would either force model developers to use very low-abstraction APIs (e.g. all code must be in a final class) or the system would rely on heuristic-based static analysis techniques that work in some cases but not others."). Koma is actually close to having a "final-only" class for

Matrix

, except for the fact that I want to support multiple backends at runtime. I'm not sure how useful that feature actually is to anyone though. If I said "only import one back-end at a time" I could probably rely on an

inline class

around the underlying memory (e.g. around the pointer on k/native to the matrix memory) or at least a final one with whatever it needs inside. Of course, before doing so I'd have to produce some metric to show its worth the pain. It's probably drowned out by other sources of slowness for now.

I see Kotlin as an alternative to Python, MATLAB, R and other dynamic languages used in the research environments for now. For the iterative modeling/testing process I believe it can show it's more productive than the current alternatives, while at the same time being more performant (relying on native implementations for heavy operations the same way these languages are doing) and being easier to deploy to a real life application. As for becoming an alternative to C/C++, it may be in some (if not many) cases that the performance loss is justified by the development gain, but a solution to the boxing problem is needed. Valhalla promises to solve this, but it will take a while (which is reasonable, the legacy problem is very complex). In the meantime if Kotlin native is optimised and supports template specialization and value types this could definitely be a C++ alternative, but there is a long way for that. I propose to focus on the first use case, there's clearly a lot to improve in the existing ecosystem and we can start right away while we wait for the performance problems to get solved.

I don’t find Julia as quick as they claim and the tooling is not that good. Plus, although Python and Julia are nice languages for prototyping, it’s different when it comes to production.

Does anyone else find themselves using name shadowing to do this:

fun someMath(phi: Double) {
    var phi = phi
    // ....
}

The one place that method parameters being final seems to annoy me is when I'm writing mathematical functions.

@altavir I made you a collaborator on Kotlin-Statistics. I created a

mpp-dev

branch that you can target your WIP to.

I added a scope document to the project https://github.com/thomasnield/kotlin-statistics/blob/master/version_2_scope.md

Think I have a way to get type-safe tensor operations up to a fixed length, but it requires code generation to implement in the general case: https://github.com/breandan/kotlingrad/blob/master/src/main/kotlin/edu/umontreal/kotlingrad/dependent/MatDemo.kt

Wish there were a better type system for numbers. It would be nice to do arithmetic on two numbers of the same type/context. Also arbitrary precision with a compiler flag would be nice. Just read this discussion: https://discuss.kotlinlang.org/t/how-to-write-generic-functions-for-all-numeric-types/7367/6