Numerics & math foundation

To flesh out, what you can build on top of typenum is very limited and this issue has an example. It's still a very cool hack.

1 Like

Oh nice, there it is!

Seems like I missed this section the last time I've check that page or it was just added lately.
Anyway, thanks for reporting!

All the important things are covered and if s.o. asks me I can point that person to this page, so currently no need to change.

(If there was a arewenumericyet page I would probably structure it by topics like Math, Physics, Biology, Bioinformatics, Chemisty, Astronomy, Geology, etc.)

Author of rulinalg here.

A great shame that linalg is
reinventing the wheel instead of building on the existing BLAS/LAPACK
optimised routines.

I don't disagree with your opinion, certainly it is a bit wasteful to rewrite all of these without a real hope of coming close in terms of performance. I just wanted to jump in and try to justify myself (ourselves at this point, though I can't speak much for the others!) a little.

It began as a hobby project and I definitely have the intention to make use of BLAS/LAPACK in the future, I just keep putting it off... I wanted to have these things exist in pure Rust because I do think there is some real value there. It's really nice to be able to access some of these linear algebra routines without having to fight your way through a forest of dependencies.

And perhaps the most important point - it's really fun! And has also been a great way for me to actually learn about some of these algorithms properly (and what it takes to optimize them).


I'd love to work with someone to improve the lapack/blas use in ndarray. It's the reason it doesn't have linalg, I didn't want to put in placeholder implementations.


@bluss I'm definitely willing to put some effort into a high-level vector/matrix library, on top of ndarray and existing blas/lapack bindings.

I noticed that ndarray has an existing linalg module. I wasn't sure how experimental that was, or if you intended to fully integrate a linear algebra toolkit into ndarray as opposed to separating it in an add-on package.


What's there is pretty good, but it's just one thing which is the general matrix multiplication function. My loose plan was to have the functionality in the crate itself, but gated behind a crate feature.

However, nothing stops us from using a separate crate instead. It's really only the trait impls for the ndarray itself that need to be in the mother crate.

We should have an irc channel for numerics & math. There's already #rust-machine-learning on mozilla's irc, but maybe we need yet another one that is more general.

1 Like

Some of them are slower now (but Rayon is not slower):

Configuration: re1: -2.00, re2: 1.00, img1: -1.50, img2: 1.50, max_iter: 4096, img_size: 2048, num_threads: 8
mandel-rust version: 0.4.0
Number of repetitive runs: 2
Rustc version: 1.18.0-nightly
Time taken for this run (serial): 11398.97166 ms
Time taken for this run (scoped_thread_pool): 2085.49592 ms
Time taken for this run (rayon_join): 1452.18856 ms
Time taken for this run (rayon_par_iter): 1452.21607 ms
Time taken for this run (rust_scoped_pool): 2087.52731 ms
Time taken for this run (job_steal): 2094.60944 ms
Time taken for this run (job_steal_join): 1457.28057 ms

Bug report?

With LLVM 4.0 the serial version is a little faster but the problem is still present:

Configuration: re1: -2.00, re2: 1.00, img1: -1.50, img2: 1.50, max_iter: 4096, img_size: 2048, num_threads: 8
mandel-rust version: 0.4.0
Number of repetitive runs: 2
Rustc version: 1.18.0-nightly
Time taken for this run (serial): 10909.90137 ms
Folder 'plot' does not exist, creating it...
Time taken for this run (scoped_thread_pool): 2077.24195 ms
Time taken for this run (rayon_join): 1445.99193 ms
Time taken for this run (rayon_par_iter): 1447.23733 ms
Time taken for this run (rust_scoped_pool): 2076.77639 ms
Time taken for this run (job_steal): 2105.99337 ms
Time taken for this run (job_steal_join): 1454.62430 ms

So, How is the development progress of these numerical and scientific libraries?

Some progress have been made but no breakthrough IIRC.
People are also waiting for some language features to appear. I wrote a blog post about it:


Thanks for keeping information posted.
Although I am not a professional programmer, but after so many years of scientific programming, I felt safety is an essential requirement for building big project. The hardest time in programming is not when the code cannot run, it is when the code has already been working for a lot cases, and suddenly, when one case which looks not so special suddenly break the quiet, and that bug is really really hard to find!!! So I value and put weight on safety, I choose to believe the ownership and borrow chain tech would solve this problem, at least partially!
So although Julia provide so many convenient way to compute, I am still waiting for Rust. Let's hope it rolls out soon.


I'm glad to hear that there are more and more scientific people out there who think this way!
Do you have some specific needs ?
There is this site:

Where you can suggest / vote for libraries you think are missing and important.

1 Like

Thanks, I think something like Numpy/Scipy in Python and Eigen in C++ will be my first need, upon which I build others by myself if I need something non-existing.

You may want to try ndarray as an alternative to numpy/scipy and nalgebra as an alternative to Eigen.

Now that we are choosing Rust as the language as the language of our next project, we surely need pure Rust libraries, otherwise, we will have a lot of unsafe keywords used in our projects, then what is the meaning of just wrapping some unsafe libraries. So if it is to be done, it should be done in pure Rust. I agree with AtheMathomo.

However, I am not saying doing the binding job is meanless, its useful for growing the Rust communities. If there is no crates, there won't be users, if there are no users, there won't be crates. So binding maybe faster than build a whole new Rust lib, and it attract users.

Yeah, I am still watching them, cause it is far from accomplished.

Nalgebra has proven good enough for my low-dimensional matrix needs so far as far as functionality is concerned. But I'm eagerly awaiting the day where const generics stabilization will allow completely revamping its API without the horrible typenums and making its rustdoc sane at last.

There are already some crates exploring this problem space (aljabar comes to mind), but the ecosystem is unlikely to consolidate until const generics hit stable.

I consider const generics as the last major language blocker before I start attempting to "sell" Rust at work. There are plenty of other "would be nice" things in the making like specialization and standard abstractions for portable SIMD, but I can work around their absence whereas there is just no clean way to work around the absence of const generics.