replace the real number trait hierarchy with a single IEEE754 `Float` trait

[thestinger]

A proper mathematical numeric hierarchy can be left to another library. I think all we need in the standard library is the ability to abstract code across different sizes of IEEE754 floating point numbers. I don't think trying to support code that's generic across both integers and floating point numbers is worth attempting in the standard library either beyond the basic operator overloads.

[thestinger]

cc @bjz

[brendanzab]

Agreed. See https://github.com/bjz/ieee754-rs

[brendanzab]

cc. @cartazio, @jensnockert, #10387

[cartazio]

yeah, I agree.

In fact, It should be made very clear that such is meant to model exactly and only IEEE floats. Its very bad / painful when apis for fundamentally different mathematical models get conflated. (eg look at any discussion that conflates Reals and Floats! :) )

[auroranockert]

I think we have thought about this for a long time, and I don't think we'll ever find a single perfect solution.

Have we considered moving all float stuff except Add, Sub, Mul, Div, Mod, Sqrt, FMA to another library? Then different parts of a program can use different math libraries, or there might grow a canonical math library more or less organically?

[brendanzab]

We could have libfloat. But I'm not sure if that is excessive. I definitely think that Float and the other numeric traits should not be automatically exported in the prelude, and using the std::num::* functions should be the normal way of doing mathematics.

[brendanzab]

One issue I can foresee is that things like string conversions need to be implemented in the std, and they rely on some float functions.

[cartazio]

IEEE Floats are something that is better off having some amount of compiler support, for all the specified operations of the standard. This is because a) it should exploit llvm compilation support b) you really want to make sure that any float operations will (by default) retain meaning during optimization

[brendanzab]

@cartazio so in your mind, an IEEE float API belongs in libstd?

[cartazio]

@bjz, Floats have a very very precise spec. How are you planning to define all the IEEE Float ops in such a way that it can be understood by both Rust and LLVM wrt suitable/correct optimizations? Are you planning on using the rust support for inline LLVM IR?

[huonw]

Are you planning on using the rust support for inline LLVM IR?

What support?

(@jensnockert: you had a branch implementing inline LLVM didn't you? Maybe we could merge it behind a feature gate, similar to asm?)

[brendanzab]

Floats have a very very precise spec

@cartazio Indeed. I have begun sketching an API out in https://github.com/bjz/ieee754-rs/blob/master/src/lib.rs, but it will be a big effort to fully implement it.

One issue is, according to @strcat, that LLVM does incorrect optimisations on floats, for example assuming that operations are commutative when they are not.