rust-ndarray VS nalgebra

Sadly Ndarray does look a little abandoned to me: https://github.com/rust-ndarray/ndarray

The date of the last commit of [ndarray](https://github.com/rust-ndarray/ndarray) lies 6 month in the past while many recent issues are open and untouched.

Burn is different: it is built around the Backend trait which encapsulates tensor primitives. Even the reverse mode automatic differentiation is just a backend that wraps another one using the decorator pattern. The goal is to make it very easy to create optimized backends and support different devices and use cases. For now, there are only 3 backends: NdArray (https://github.com/rust-ndarray/ndarray) for a pure rust solution, Tch (https://github.com/LaurentMazare/tch-rs) for an easy access to CUDA and cuDNN optimized operations and the ADBackendDecorator making any backend differentiable. I am now refactoring the internal backend API to make it as easy as possible to plug in new ones.

Looks like it's an open request

https://github.com/rust-ndarray/ndarray/issues/281

Answer: you can’t with this crate. I implemented a dynamic n-dim solution myself but it uses views of integer indices that get copied to a new array, which have indexes to another flattened array in order to avoid duplication of possibly massive amounts of n-dimensional data; using the crate alone, copying all the array data would be unavoidable.

Ultimately I’ve had to make my own axis shifting and windowing mechanisms. But the crate is still a useful lib and continuing effort.

While I don’t mind getting into the weeds, these kinds of side efforts can really impact context focus so it’s just something to be aware of.

In principle you're trying to convert between columnar and row-based data layouts, something that happens fairly often in data science. I bet there's some hyper-efficient SIMD magic that could be invoked for these slicing operations (and maybe the iterator solution does exactly that). Might be worth taking a look at how the relevant Rust libraries like ndarray do it.

ndarray and numpy crates provide good way to operate on numpy ndarrays from python

I don't think any of the major ML projects have GPU acceleration because ndarray doesn't support it.

Not sure about ndarray: https://github.com/rust-ndarray/ndarray/issues/840

I used basic_dsp a while back and found it lacking. I was hoping to find something that uses the ndarray datatype but i'm not seeing this yet. If you're primarily trying to learn though it might not really matter which library you contribute to. As for myself, I just picked the one that was most used and actively worked on at the time. However I keep an eye out on other libraries; if I see something take off, I might switch over. Either way you'll learn and can point to it as work accomplished.

Maybe start by looking at https://nalgebra.org/ to see what rust math libraries might look like

And Nalgebra, while better, also seems to have slowed down on commits and responses to issues and PRs. I have a PR there for a relatively simple wrapper type for row vectors which was explicitly requested by a maintainer, which hasn't even gotten a comment since for two weeks.

nalgebra (similar to Eigen in cpp)

nalgebra

Take a look into math libraries, like glam, nalgebra, and cgmath. I've only used these through game engines, though, so I can't offer per-basis reviews/advice.

If you do not need GPU then I would recommend looking into Eigen in C++, nalgebra in Rust (with a BLAS in both cases for improved performance) or one of the above options (Julia / Python+JAX).

I coded it in rust, with the very good lib nalgebra for the vector, point, matrix and SVD computation and petgraph for the graph, and I'm very happy with my math heavy, computer vision and no brute force solution.

It looks like nalgebra is already working on adding support for rust CUDA: https://github.com/dimforge/nalgebra/pull/1031

Actually I would disagree with this somewhat. It's not as built out as Julia or python with third party crates, but that is likely to keep improving. The ability to implement the traits in std::ops means that the natural use of +, *, etc to "add" or "multiply" custom types is possible. There is already rug for big number / high precision calculations, nalgebra for linear algebra, among a couple others for ode solving etc. Rust's iterators are also ergonomically magnificent for math involving iteration. Where I would agree it is less ergonomic is for scientists that don't care about the speed gains from the rust memory management system having to deal with the borrow checker. With a little understanding of the way that works, it doesn't get in the way much IMO. Not saying it will ever be a go to language for scientific computation, just that it's more than possible, and can be just as enjoyable.