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

[nicolasboulay]

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.

[huonw]

This sounds like it's very similar to #8937.

[nicolasboulay]

It's related to number, but that's the only common point.

Such proposal enable very fast code with readable code, that's not the point for BigInt.

Usually mathematical simplification are done with an other tools, here compiler could do the job (or an external component because lot of thing could be done).

[huonw]

I can't tell from your response if you noticed that #8937 is for BigDecimal (i.e. an arbitrary precision Real type, although with base 10 rather than base 2), rather than BigInt.

(My apologies if you did. :) )

[nicolasboulay]

Yes i did :)
arbitrary precision arithmétique are very specific (financial operation, some scientifique computation).

Here, it's about to write high level code where operation are readable, and compiler do it's job and check the coherency. It's for HPC, Game, Display, signal processing, simulation.

For exemple, if you wrote a display library, you want a subpixel precision but not more. So your trigonometric operation could be simplified, within the range and precision specified. With IEEE754 float, no controled optimisation could be done.

Basically, optimisation are done with classical math, then the register type ("layout" of the data) are choosed to keep the precision (float, double or BigFloat) or even Integer for faster fix point operation or a mix of all.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#335

[rust-highfive]

This issue has been moved to the RFCs repo: rust-num/num#9

[nicolasboulay]

It's in the old comments, this has absolutly nothing to do, with bigInt or bigDecimal. That's for common code.

This is WRONG to put it with "num", it's related to the compiler, not with a library.

[thestinger]

Compiler support is only necessary when there's hardware support to leverage. Optimizations are possible for number types like this, but that's also true of types like big integers. Rust currently doesn't perform optimizations outside of LLVM. It doesn't have any kind of IR above the LLVM layer where optimization passes could be performed.

[thestinger]

Either this issue is a feature request for a new type in the number library or you're proposing a major language addition which needs to go through the formal RFC process.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#678