I am currently working on a project that requires trigonometry operations on relatively small distances and angles. The programme is supposed to run on 64 bit systems, and that length should be enough for the purpose. However, I am unable to find such functionality in the core or in the crate registry.

I am aware of the following crates:

rust_math: only works on 32 bit floats and at least the arc-cosine function is currently failing.

astro_float: implements its own float type, which beyond being overkill for my use case, can not be converted back to f64.

Would there be another option out there? Thank you.

Thanks. Seems like all I need at this moment is here. I was searching for function names like arccos or arctan and never got to this documentation page.

How small are the angles? In some cases the standard functions might not be enough, e.g. if you want to compute 1 - cos(x) for x near zero, because of catastrophic cancellation.

Aliases might help.
I found the docs confusing a bit at first. I understand the math functions are "attached" to the "types" so their docs are in the docs for the types (f32, etc). I think there also should be a section somewhere in the std docs with "math" functions. Linked to by the top std module page. Of course after I figured out where to look (in the types) finding the math functions was easy.
NOTE: searching the std docs for "math" finds stuff for "path" and "trig" goes even more sideways trignored

I don't think anything screams "math" better than a function being literally associated with a numeric type.

Why the obsession with transcendental functions? If they should have a separate section in the docs, why shouldn't any other kind of function? I mean, the first place I would look for math functions is numeric types, that'sā¦ not exactly hidden.

This is possibly a case of expectations depending on your language background. C, C++ and Python at least don't have math functions (or any functions) on primitive types. In fact I can't think of any language that I know that does. So it seems reasonable if you have such a background to assume it is the same in Rust too.

It can be insightful to look at the world from the perspective of others sometimes.

It doesn't help that the Rust standard library renamed some functions (e.g. the logarithm, log1p, etc.) and is missing some others (Bessel functions, the Gamma function, the error function, etc.).

I'm not aware of any renaming, that would have broken backwards compatibility big time.

If you mean they don't have exactly the same name as they have in C, then: it's a different language. It's easy enough to find ln_1p if you scroll the left sidebar a little bit.

The standard library is intentionally minimalistic. Bessel and Gamma functions are pretty niche, but you could probably make a case for erf in an RFC. Otherwise, for statistics-specific functions, use the statrs crate.

When you're searching by a name, there's nothing to scroll. Searching for log1p just returns log10. As for special functions, how are you supposed to know about what other crates to use? Why statrs and not libm? It's something the Rust documentation could include. ("Looking for erf? See the libm crate.")

Yep. The "Book" gives a whole chapter to strings. If you search for "Math" in The Book, you still find nothing. Yes, you and I know to look in the primitive types for the functions that work on those types. But "math" is so common, newbies will look for the math functions first. It takes a step in the rust learning process to get to the point where you understand that the operations are tied to the types. Almost like "objects" but called "types" and technically different.

Yeah. Strings are a small, self-contained concept directly relevant to programming.

"Math" is a whole scientific discipline. How exactly would you expect Rust documentation to cover "math"? That seems absolutely unrealistic. There has been a lot of talk abut Bessel functions and the Gamma function above, which are solutions to advanced differential equations that come up in university-level complex analysis and statistics. Do you really think that Rust documentation should include differential equations, probability theory and statistics, and complex analysis as subchapters? That can't possibly be a serious demand.