Kyle Kauffman
Kyle Kauffman
As a result of switching to PCG in #82 we lost the random default seed. We should re-enable when we bump our kotlin dep to 1.3 and can thus access...
In #78 it was proposed that we have two string representation methods for containers: `toString()` which presents a clear human-readable output like `[1, 2, 3]`, and `repr()` which would produce...
Using gradle's builtin string replacement leads to complicated codegen because our generation requirements aren't quite that straight forward (see #74 for example). It may be worth considering moving to a...
Right now the top-level koma functions often assume that we are dealing with double-valued matrices. For some cases this is a reasonable default, for example `zeros(3,3)` creates a double-valued matrix...
It may make sense to refactor out the code that converts linear indices into N-dimensional indices and vice versa into a separate object that could be re-used. See discussion in...
There's some things that could use further explanation. In particular: 1. The codegen process, why we have it, and how to modify it for contributors (this might actually be best...
Now that uint will be a builtin kotlin feature, we should deprecate our uint support entirely. In addition, inline classes leave us an avenue to support complex matrices without boxing,...
Now that inline classes look slated for kotlin mainline (experimental in 1.3-M2), it would be very useful to implement `Matrix` with inline classes to eliminate any overhead using koma might...
For the js side, we may end up needing two backends: one for node (which calls out to optimized blas, see e.g. Vectorious) and one for everything else (browser, etc)....
Currently koma only tests itself on the jvm. It needs to instead switch to kotlin-test and test on all 3 backends, as well as extend test coverage.