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.

[cartazio]

@bjz yes, and most of those operations (as I understand it) should have an LLVM IR analogue operation. (though doing a software implementation would be valuable too! )

[cartazio]

@huonw theres no way to have peformant float ops as a userland lib if it can't hook into generating the right LLVM / compiler IR primops :)

[cartazio]

so if having special inline llvm IR is something Rust can robustly support going forward, theres very very little cost to having all the float stuff be userland for now I guess. (though it does make providing any floating point analysis/optmization support in the rust Compiler a bit harder to add! )

[huonw]

(I was just pointing out that we don't have support yet.)

[cartazio]

oh ok. :)
so in the mean time, hardware supported floats need to have all their operations baked into rust :)

[auroranockert]

@huonw: I'll take a look at it, when I did it, there were no feature gates, and I'm pretty sure everyone involved didn't want to unleash such terror on the language. But with feature gates, it could help the few people who need it, like the libstd implementors.

@cartazio: Yeah, but that's only a few. Most of IEEE 754-2008 has to be implemented in software.

[cartazio]

fair enough, I guess most of the hardware support for the fancy functions just gives a decent intial estimate for a fixed iteration count newton method solvers or special lookup tables plus interpolation, so i mispoke before (long weekend, lots of travel)

[brendanzab]

Should we anticipate there being more hardware support available in the future though?

[auroranockert]

I doubt it, modern architectures seem to have less hardware than older ones. x87 did everything in microcode, SSE had hardware only for the basic ops (neg, add, sub, mul, div, sqrt, round), Itanium had hardware only for FMA and rounding.

[thestinger]

@bjz: The parts not supported properly by LLVM are the floating point rounding mode, signalling NaN and floating point exceptions. There's no way to work around this in Rust. It has to be implemented in LLVM.

The optimizations changing results are only performed if fpmath metadata is used to mark the permitted error or some subset of the fast-math flags are enabled via metadata.

[thestinger]

In my opinion, the standard library support should simply look like https://github.com/thestinger/rust-core/blob/master/core/f64.rs. At most, these should all be moved to a single Float trait for abstracting over different sizes of IEEE754 floats but no attempt should be made to include them in a numeric hierarchy.

[brendanzab]

Agreed.

By the way, to do the best job of an IEEE 754 trait, associated items would be most appreciated so that we can express LogBFormat and IntegralFormat outside of trait type parameters. fn foo<LB, I, Float<LB, I>>(...) would be a massive pain.

[alexcrichton]

Closing, this is done now.