Hacker News Reader

Comment by mintplant | Hacker News Reader

> Consequences ? You can’t use Rust arrays to represent a matrix bigger than 4×8, how useful is that?

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.

Also, those are memory slices, not arrays: they aren't pointers to heap-allocated data. So [[f32; 9]; 5] corresponds to a contiguous block of memory representing a 5x9 matrix of 32-bit floats. It has the same memory structure as [f32; 45], but you can index it as eg. my_matrix[3][2] to access the element in the 2nd column of the 3rd row. Again, I guess it's much easier to bash something than try to understand it.

View on HN

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

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?

I believe the author is lamenting the absence of RFC 2000 (const generics.) That is, users cannot define their own types which are generic over constant values.

Just because language X can wrap a LAPACK/BLAS library doesn't automatically make it fit for the purpose of implementing one.

Look at how the nalgebra represents an n-dimensional array of known dimensionality (through both the type system and in memory) and you will understand.

Once there is, say, a uBLAS equivalent in rust that is easy to use and understand the implementation of, I will consider it worthy.

The generic-array and typenum crates solve this at the type level. nalgebra uses typenum to encode dimensions at the type level, not in memory/at runtime (unless you opt-in with the `Dynamic` marker type). RFC 2000 will ease this, but it's not impossible to do at present.

It's a fair criticism though, don't you think that in order to use a fundamental aspect of a language (Arrays), one needs to download some external package? Why isn't this built into the core language?

See the second paragraph of my comment with regard to representing matrices efficiently with just slices. I would argue that Rust is actually better here than most languages, as its native multidimensional "arrays" (slices) are equivalent in memory usage and performance to single-dimensional ones.

More generally, the 1-32 issue should be solved when RFC 2000 is implemented [0]. In the meantime there's generic-array [1], built on top of typenum [2], which you could think of as a sort of polyfill.

[0] https://github.com/rust-lang/rfcs/blob/master/text/2000-cons...

[1] https://github.com/fizyk20/generic-array

[2] https://github.com/paholg/typenum

Thank you for clarifying.

Reply on news.ycombinator.com