add math functions (`sin`, `cos`, etc.)

[japaric]

There's a WIP C free implementation of these math functions in the m crate so let's use that. The tricky part is that the m crate exposes the functionality as traits but std must expose that functionality as inherent methods. So you'll have to do something like this (not tested):

use m::Float;

#[lang = "f32"]
impl {
    fn abs(self) -> Self {
        <f32 as Float>::abs(self)
    }
}

[anatol]

Just started working on this issue. Here is the repo https://github.com/anatol/steed/tree/issue_8

As it turned out there libstd uses 36 math functions from libm. 2 of them are implemented in @japaric's m crate. The other math functions need to be implemented. I think that the best to do it is to look at musl implementation https://git.musl-libc.org/cgit/musl/tree/src/math and port them one by one. But I would not say it is an "Easy" task.

I have a question about the m crate. It has its own implementation for sign checking and abs. What is its advantage over libstd implementation?

[anatol]

Somebody mentioned math.rs crate that implements a good chunk of Float math functions. no_std users can use that crate directly. Does it still make sense to include math support to steed? If yes - can math.rs implementation be reused?

[japaric]

I have a question about the m crate. It has its own implementation for sign checking and abs. What is its advantage over libstd implementation?

The m crate is meant for stable no_std contexts. The abs implementation in libcore is unstable.

Somebody mentioned math.rs crate that implements a good chunk of Float math functions.

I'm fine with using any other crate. BUT, whatever crate we end up using, it must be tested for precision. The m crate has this in the form of quickcheck tests that compare against the GNU libm implementation. math.rs doesn't seem to have precision tests.

[anatol]

@japaric Indeed I checked a few math.rs functions and found that its cos() gives a result that is slightly different from glibc one. https://github.com/nagisa/math.rs/issues/1

On a positive side many other functions work correctly and performance of the that Rust implementation is the same (plus/minus noise) as implemented in C.

[nagisa]

BUT, whatever crate we end up using, it must be tested for precision. The m crate has this in the form of quickcheck tests that compare against the GNU libm implementation. math.rs doesn't seem to have precision tests.

In my defence when I was implementing (2 years ago now!!) math.rs the most viable way to check against another library was to invent corner case tests for myself :) I’m aware of my implementation being lackluster in that regard, but that’s nothing which couldn’t be eventually fixed :)

Ideally we wouldn’t be duplicating the work done and merge the implementations. Sadly the licenses aren’t quite compatible, so you can’t just copy the openlibm ports to math.rs, sadly.