Rust isn't really a mathematical language like Julia is.
num is a library of mathematical traits.
But here's the real sticker for making this a
- What types (other than library
Matrix types) should implement
- Note that many matrix-providing libraries like numpy implement matrix inversion copyless by dynamically switching between a row-major and a column-major interpretation of the data.
[[T; N]; M] would be expensive to reorganize to invert to
[[T; M]; N].
- Plus most users would prefer
Matrix<M, N> to
[[T; M], N] anyway, for indexing
[(row, col)] rather than
- What functionality can meaningfully be input parametric over
Inv types (probably with other bounds as well)?
If the trait exists solely just to collect the same functionality under one name, but is not really meaningful as input parametricity, it doesn't really deserve (/need) to be a trait.
TL;DR I don't see any benefit of "matrix inversion" being a standard trait if there isn't even a matrix type in std. And
[[T; N]; M] isn't a matrix, it's an array of arrays, which is often used to implement a matrix. And if nothing other than matrices can be inverted, then it would be better as a
MatrixOps trait, imho, and that would live in the numpy equivalent for Rust (currently, ~num/nalgebra/ndarray, will definitely shift some when const generics stabilize.).