Hi, could anybody suggest something resembling num...

# datascience

[Igor Alshannikov]

Hi, could anybody suggest something resembling numpy's meshgrid() and multivariateNormal() in the current Kotlin ecosystem?
I'm looking to rewrite code in these notebooks without `kotlin-numpy`:

https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks/contours.ipynb

https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks/density_2d.ipynb

[altavir]

I never understood the meaning of meshgrid since it does not store any useful data, but here is a basic example how to do it in mostly pure kotlin (I only use grid generator from KMath, but it also is like 3 lines of code): https://datalore.jetbrains.com/view/notebook/lhNLFo1aTUhrjTCFN4zbJH

[altavir]

Mulitvariate normal with covariance is a little bit more tricky, and requires some work. Here is a sample using commons-math: https://datalore.jetbrains.com/view/notebook/DrsdWeFRFr3KmG2C68MaOI

The API is not quite kotlin-friendly, we can improve that. If you woild leave an issue in KMath, we would add that to our new tensor API helpers.

[Igor Alshannikov]

Thank you! I'll try "multivariate". Regarding 'meshgrid' I was hoping to get away without writing the meshing code) Also, your algorithm is not correct unfortunately.

BTW, was this a deliberate decision not to target java 1.8 when compiling KMath?

[altavir]

I was writing the algorithm from my head, so I could have confused directions. My point is that meshgrid is not an informative construct and it was created to accomodate some defficiences in numpy API.

[altavir]

As for JDK version, yes, it was intentional. The library is under heavy development and when it will it be fully stable, JVM 8 won't be supported anymore. So unless someone leaves an issue that thay need JVM 8, it will target 11. It is much easies to extend the support now, than to shrink it later.

[altavir]

We plan to add support for JDK 17 in a separate module though without breaking the compatibility with 11 for the core.

[altavir]

By the way, the example uses outdated stable version of KMath, now we have better building of buffers as well as better rendering.

[Igor Alshannikov]

Why supporting JDK 17 requires a separate module? I'm asking because we also have requests to make lets-plot JVM artifacts "modular" but I haven't researched it yet.

[altavir]

The thing is that in order to consume a library, you need to run on an appropriate version of JVM. If you a running on Java 11, you can't use library written for JVM 17. But in some cases you want newer JVM features. This is solved by compiling the core module for older JVM and adding additional module that will depend on the core and will target newer JVM. The same way Kotlin stdlib-jdk8 works.

In newer Java versions there are also multi-release jars, that contain bytecode for different JVMs, but I do not think it makes sense.

[holgerbrandl]

What about https://commons.apache.org/proper/commons-math/javadocs/api-3.3/org/apache/commons/math3/distribution/MultivariateNormalDistribution.html

[Igor Alshannikov]

Exactly ) : https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks/density_2d.ipynb

In the case of 'meshgrid' I had no choice but code it : https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks/contours.ipynb