3 ms·
If the author wanted to write his own, he could very easily write an nd-array-alike wrapping a really long double[] in Rust, right? From the author: You can w
by jbooth 9y ago
If the author wanted to write his own, he could very easily write an nd-array-alike wrapping a really long double[] in Rust, right?
From the author: You can work around it by using a Vec (arbitrary sized sequence/list) but then your matrix is allocated on the heap not the stack, meaning slower operations. Plus that means you cannot use Rust wonderful type system to check that you multiply matrices with compatible dimensions, say a 2×2 matrix with a 2×1 matrix, without jumping through hoops.
So he thought of that, then decided not to go that way, even though that's how it's done in C/Fortran underneath every single linear algebra library in the world, and his conclusion is that rust sucks?
I'm finding it a little hard to believe that there are real-world linear algebra problems where allocation is the bottleneck and doing it all on the stack is the answer.
- Typhon 9y agoIf you have to do X in the new language in the same way as in Fortran, the new language is not better for doing X than Fortran, is it ?
- jbooth 9y agoSure it is. Both in larger program design and in affording several different ways to accomplish the subscripting into the giant nd-array Vec<f64>. Maybe Rust should also provide language support for the ndarray type, but lack of such isn't a barrier to being as-good/better than existing langauges. If you're doing linear algebra on big matrices, putting them on the stack is most likely madness. It sounds like the author is interested in Rust for the 'expressive' type system enforcing logical invariants about his matrices, which isn't why Rust built their expressive type system.