pre-Proposal: Math Working Group

I propose to create a math working group to focus on the healthy development of the Rust language numerical calculation system.

First, clarify that although the working group expects to cover scientific computing content (refer to Matlab, Wolfram Mathematica, etc), it still proposes to simply call as math working group.

I wonder why there is no math working group in Rust? Numerical calculations are important to any language, even for rust language that was not born for numerical calculations.

The responsibilities of the working group roughly include the followings:

  1. Organize and propose the crate-chain of scientific computing;
  2. Define certain crates as "working group recommended" in the crate-chain to reduce the selection difficulty for novices;
  3. Identify missing crates in mathematics, such as symbolic calculations, PDE solvers, etc. for now, and mark some missing crates as "urgently needed";
  4. For some key missing crates, the working group can also create projects and implement them;
  5. And more things that I didn't expect now;

I hope that this proposal can be supported by the community, and that the working group can be formed by community numerical computing experts. I will also try my best to devote time to support this working group.


You may get more interest on this if you repost it in the Rust users' forum. This forum is dedicated to Rust language and tooling issues, so is less likely to be read by your intended audience.


I've created an algebraic numbers crate, that should be useful for some things. I also created a non-official reference implementation of IEEE 754 floating-point based on the algebraic numbers crate -- intended to be easy to understand to assure correctness rather than being fast.


There's the rust-num project which gives you bigInts and Complex types, but it's still missing tons of algorithms (gcd, fft etc)

1 Like

Hello, I'm a student of math and I have done research related to numerical computing mostly for statistical modeling.

1 Like

I'm all for this...

One of the big additions I was hoping to make that might be slightly controversial is to make a 32 bit version of most of the basic math functions.

I haven't looked into it carefully yet, but from what I've seen, many (all?) math functions are only implemented in f64 and then truncated back to f32...

Not only is that slower, but in many cases it is frustrating when the truncated result is different from the rounded result.

1 Like

This is probably platform-dependent. For most of these things Rust just calls the platform library; it's not implementing them itself. So if you want something better, check your libm.

1 Like

I'm confused... When I look at the source for cos ( I only see a f64 implementation:

... pub fn cos(x: f64) -> f64 { ...

It's my understanding that all platforms would use this standard code even a 32 bit cpu for example, although I could be wrong.

1 Like

I think you’re wrong. What’s getting called is the cosf32 or cosf64 intrinsic which then get compiled in a platform-dependent way. For example on linux-gnu, this seems to be calling into the system libc/libm/whatever_it’s_called functions cos and cosf (see e.g. this assembly). Those would then be pre-installed libraries on your system, probably implemented in C, dynamically loaded when you run the Rust program.

1 Like

It might be nice to have this as a GPU kernel:

1 Like

I then posted in the Rust users' forum

@programmerjake @elichai2 @oliver @carrybit and more, Thanks for all your guys' reply. I would be glad to make this work with you guys.

Lately, I am working on extracting information from Something like that and far away from perfect

Also, I may get some volunteers and even funds to support the working group.

1 Like

At which layer(s) do you suppose a WG for math internals goes out of scope?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.