Its unfortunate that kmath appears to be going dow...

# mathematics

[kyonifer]

Its unfortunate that kmath appears to be going down the same road koma did and encountering the same challenges. In the git history, you'll see koma too started out generic and eventually ended up needing to have codegen to make things even somewhat fast. Even so, "somewhat fast" is the best that possible, not "fast". I think ultimately language support will be required if scientific computing is going to be popular in kotlin (without a 2-language solution, like python/c). While it might be reasonably for us to say "oh we'll just specialize a few things by hand for a few use cases", we cannot expect every library author out there that wants to implement a generic algorithm to do so. Right now, if someone wants to write something like fun <T: FloatingPoint> expm(m: Matrix<T>){ ... m.get(i,j) ... } in Kotlin one really cannot do so without being extremely slow due to boxing, virtual calls, etc.. Yet there are many languages where doing this is possible.