[UR] true "real" type, not a IEEE754 one.

Issue by nicolasboulay
Thursday Jan 23, 2014 at 10:09 GMT

For earlier discussion, see https://github.com/rust-lang/rust/issues/11749

This issue was labelled with: B-RFC, I-enhancement in the Rust repository

IEEE754 number are not real. Almost none typical mathematical transformation can be applied without loosing precision and changing bit. Most of compiler did nothing with such type, and --fast-math behaviour can't be predicted.

I propose to add a real type, with needed precision and range added as type parameter.

This precision should be absolute, because relative precision make problem around zero. An in real world, sensor have absolute error specification most of the time. System specification use also use absolute number. Relative precision match well floating point implementation (but not around zero) but that's all. With range, relative precision could be calculated if needed.

With precision and range for input and output, any transformation could be evaluated, and loss of precision could be accepted or not. Typical Math became available. There is no more limitation as for IEEE754 number.

Underlying layout could be 64 bits floating point number, but compiler could choose 32 bits or fixed point number, because it has all information in hand to do the job.

Start by reading the earlier discussion in rust-lang/rust#11749 and the proposal in this issue. The issue does not name files, tests, or entry points; completion would require a settled design for a parameterized real type, its precision and range semantics, and compiler-selected representations.