Hello guys, yesterday we had a talk with <@U2E974E...

# datascience

[altavir]

Hello guys, yesterday we had a talk with @elizarov about development of scientific/mathematics libraries for kotlin and he recommended to start a discussion here since we do not have dedicated channel for that. My team is working on a bunch of scientific libraries (the application is mostly physics, but they should be universal). Currently we are working on a basic mathematics (https://github.com/altavir/kmath/tree/dev). I personally think that Kotlin has a great future as a language for science so, it would be good to create a robust scientific community around.

So, speaking about math, in kmath we use rather experimental approach using unique context oriented kotlin features rather than copying details from python. I studied https://github.com/kyonifer/koma and there are a lot of good things there and a lot of work done. I think, that we need that library or something similar for people coming form Python, but sadly it does not suite more advanced mathematics use that we need. Python style is probably good for data science, but the type system is too crude do something complicated. My proposition is to devise a common mathematics interfaces and specifications for kotlin/multiplatform and then ensure that all implementations follow those interfaces. The same goes for plotting (we are currently working on plotting interfaces similar to matplotlib in functionality, but with modern declarative api).

[thomasnield]

You are definitely going to want to talk to @kyonifer as he's already been trying to extract common interfaces with Koma and backing them with multiplatform implementions. There are a couple of scientific JVM libraries already, like Apache Commons Math, ND4J, and ojAlgo. But Koma is the most concerted effort to support multiplatform Kotlin scientific computing.

[altavir]

This is the plan. Frankly speaking, In my opinion. koma takes too many bad things from Python. But we need to discuss it, because everyone have different background.

[ValV]

In my view, it would be interesting, if you introduce your own way

[altavir]

The problem with koma is that it follows numpy almost precisely. And numpy was designed with python defficiencies in mind. What we (I mean our group) need is a flexible type system and ability to do some advanced things like expressions and lazily evaluated objects. Current kmath (maybe it is more correct to rename it to kontext-math) follows the tradition started with commons-math, namely using algebra abstractions as types. It is in early development stage and maybe looks overcomplicated. Today I wrote two small texts for documentation: https://github.com/altavir/kmath/tree/dev/doc, maybe you could get an idea from them.

[altavir]

What I currently don't have is an implementation using existing libraries, so I will look into koma implementation.

[breandan]

I really like the idea of defining these structures using algebra, recently started playing with a similar project and feel these kinda of abstractions would be useful for more general-purpose mathematics libraries: https://github.com/breandan/algebraik

[altavir]

We should probably think together. I think that the starting point is to somehow create a base of use-cases. Maybe create a separate repository for keep-like proposals and discussions?

[breandan]

Maybe this discussion is more appropriate for #mathematics.

Re: Collaboration, sure! I'm happy to be involved in the discussion. I think a Kotlin-native mathematics library should ideally leverage the type system to its full extent. There are some existing libraries for building numerical abstractions, although I'm not about the performance tradeoffs here (ex. https://github.com/non/spire). But you certainly could build such a library from first principles (Group, Ring, Field, etc.) using lazy evaluation and functional programming...

[altavir]

OK, let's go there .I did not know, it exists.

[breandan]

https://kotlinlang.slack.com/archives/CE5HPKBRN/p1545843879002700

[bjonnh]

@altavir There is #science too