For floating-point operations and expression intermediate values, a greater precision can be used than the type of the expression. Only the minimum precision is set by the types of the operands, not the maximum.Implementation Note: On Intel x86 machines, for example, it is expected (but not required) that the intermediate calculations be done to the full 80 bits of precision implemented by the hardware.
Execution of floating-point expressions may yield a result of greater precision than dictated by the source.
Regardless of the type of the operands, floating-point constant folding is done inreal or greater precision. It is always done followingIEEE-754 rules and round-to-nearest is used.
Floating-point constants are internally represented in the implementation in at leastreal precision, regardless of the constant's type. The extra precision is available for constant folding. Committing to the precision of the result is done as late as possible in the compilation process. For example:
constfloat f = 0.2f;writeln(f - 0.2);
will print 0. A non-const static variable's value cannot be propagated at compile time, so:
staticfloat f = 0.2f;writeln(f - 0.2);
will print 2.98023e-09. Hex floating-point constants can also be used when specific floating-point bit patterns are needed that are unaffected by rounding. To find the hex value of 0.2f:
import std.stdio;void main(){ writefln("%a", 0.2f);}
which is 0x1.99999ap-3. Using the hex constant:
constfloat f = 0x1.99999ap-3f;writeln(f - 0.2);
prints 2.98023e-09.
Different compiler settings, optimization settings, and inlining settings can affect opportunities for constant folding, therefore the results of floating-point calculations may differ depending on those settings.
IEEE 754 floating-point arithmetic includes the ability to set 4 different rounding modes. These are accessible via the functions incore.stdc.fenv.
If the floating-point rounding mode is changed within a function, it must be restored before the function exits. If this rule is violated (for example, by the use of inline asm), the rounding mode used for subsequent calculations is undefined.
IEEE 754 floating-point arithmetic can set several flags based on what happened with a computation:
| FE_INVALID |
| FE_DENORMAL |
| FE_DIVBYZERO |
| FE_OVERFLOW |
| FE_UNDERFLOW |
| FE_INEXACT |
These flags can be set/reset via the functions incore.stdc.fenv.
An implementation may perform transformations on floating-point computations in order to reduce their strength.
Not all transformations are valid: The following transformations of floating-point expressions are not allowed because under IEEE rules they could produce different results.
| transformation | comments |
|---|---|
| x + 0 →x | not valid ifx is -0 |
| x - 0 →x | not valid ifx is ±0 and rounding is towards -∞ |
| -x ↔ 0 -x | not valid ifx is +0 |
| x -x → 0 | not valid ifx is NaN or ±∞ |
| x -y ↔ -(y -x) | not valid because (1-1=+0) whereas -(1-1)=-0 |
| x * 0 → 0 | not valid ifx is NaN or ±∞ |
| x /c ↔x * (1/c) | valid if (1/c) yields an exact result |
| x !=x → false | not valid ifx is a NaN |
| x ==x → true | not valid ifx is a NaN |
| x !opy ↔ !(xopy) | not valid ifx ory is a NaN |
Of course, transformations that would alter side effects are also invalid.
