Some floating point math functions produce different results on windows

[brson]

Mostly dealing with NaN and infinity. See stdtest/math.rs. Some of the tests are commented out because they produce different results on windows.

Since they are just wrappers around the C functions it's not clear whether we should tolerate the differences or try to be consistent. I'm inclined to make them all behave the same on any platform.

[boggle]

Making them behave identical across platforms will incur a performance penalty for some calls on some platforms. I think that this is not acceptable for performance critical calls like pow(). This leaves us with three alternatives:

(a) define the deviating behavior as officially undefined and thereby push the burden of handling this to the user

(b) use our own implementation of floating point ops, perhaps by incorporating some C math library directly into the rust runtime or at least allowing easy integration with a common math library

(c) complete implementation of libm in rust. This would be very nice but also very much work and requires someone who knows how to write fast numeric code.

For case (b), this is a list of possible candidates from a quick search

• http://lipforge.ens-lyon.fr/www/crlibm/links.html
• http://sourceware.org/newlib/libm.html
• BSD libm

[kud1ing]

Are there any numbers for the cost of such platform-independent code?

I think having platform-independent code in the standard library is crucial.
People who find that the performance-costs unbearable might choose to write platform-dependent code by using cmath.rs et al.

CRlibm seems out of question, giving its LGPL license. See also http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplacingGMPastheBignumlibrary

[boggle]

Well, I did not measure this but it certainly would require a series of extra compares or at least a switch per call. This means the costs are at least an extra compare and an extra jump, if not more, and will negatively impact branch prediction. For some calls, this may be unacceptable in inner loop code and make rust on that particular platform suffer unduely in terms of raw performance.

Unless somebody finds a suitable version of libm, I would actually tend towards (a) for now, and aim for (c) later.

[boggle]

Just found this:

• https://github.com/ViralBShah/openlibm

Hmm maybe it would be enough to have a configure option for switching the libm in use for now?

[bblum]

re-nominating well-covered, not production-ready

[graydon]

accepted for well-defined milestone

[graydon]

accepted for production-ready milestone

[graydon]

accepted for production-ready milestone

[thestinger]

This is caused by mingw's implementations of these functions being incomplete on Windows.

[klutzy]

So this is #8663, right?

[catamorphism]

Not 1.0, high