Hacker News Reader

Comment by coldtea | Hacker News Reader

>I went and Google'd "rust linear algebra library" and immediately found https://nalgebra.org which can represent such matrices just fine, and even integrates with LAPACK. Did the author do this most cursory of research before springing to write their rant? This is like saying "Python fails hard at scientific computing" because the default list type isn't an efficient basis for representing matrices, while entirely ignoring NumPy.

The author didn't want to use/leverage/whatever some ready made package. He wanted to write his own.

Python does suck for scientific computing at that level as well -- Numpy and Scipy are huge wrappers for C/Fortran etc code.

View on HN

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.

If 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 ?

Sure 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.

The authors of nalgebra seem to have succeeded where the author failed, then. Perhaps because they took the time to understand what slices are.

The author didn't say it was impossible altogether -- just that he would want actual malleable first-class multi-dimensional array types.

So... nested slices? Unless you have some special meaning attached to "malleable".

Good point.

I guess this also holds for graph-problems, where graphs are possibly cyclic structures (difficult memory management), and/or stored as adjacency matrices.

PS: Is there a set of benchmark problems that can be used to validate a language design?

Reply on news.ycombinator.com