brandondube / linalg Goto Github PK

Running go test . yields

--- FAIL: TestSquareMatrixInvert (0.00s)
    mat_test.go:230: [[NaN NaN] [NaN NaN]]
    mat_test.go:232: matrix inversion did not match expectation
FAIL
FAIL    github.com/brandondube/linalg   0.002s
FAIL

I understand linalg has the purpose to be a compact linear algebra memory. This is something that also is of use to me since gonum does not see binary bloat and overhead as an issue that needs fixing.

However, the low-levelness of this library is too far down for me to reach. I have created a fork with a draft of what works for me. I don't want to convince you to change this repo if my fork is not in line with your vision, since I understand you deal with real-time stuff.

However, if you find that maybe with a few changes my fork can be acceptable for use in your applications maybe we can merge some of it to this repo and see how it goes from there. As I said, it's all good either way :)

Main differences With this repo:

• Types for matrices and vectors. Functions are then sectioned off as methods.
• Transpose function renamed to T

Some pointers on my vision:

• Let users provide their own scratch and don't have package wide scratch pools.
• Loosely coupled interfaces. Like I mentioned in the issue above, avoid coupling interfaces to the package, this results in binary bloat and long compile times
• Have types for dense, sparse matrices, vectors.
• Correctness: Avoid letting users do incorrect operations. Right now this repo lets users operate on overlapping memory!
• Compactness: Be usable with tinygo with small binary size. Prefer compact algorithms to optimized algorithms.

Some things I am willing to reconsider

• Maybe the DenseM type could be of underlying type float64[][], worth benchmarking to see if performance hit is big, probably is not

Let me know what you think!