Always false float comparisons

[Timon Gehr via Digitalmars-d]

On 13.05.2016 23:35, Walter Bright wrote:
> On 5/13/2016 12:48 PM, Timon Gehr wrote:
>> IMO the compiler should never be allowed to use a precision different
>> from the one specified.
>
> I take it you've never been bitten by accumulated errors :-)
> ...

If that was the case it would be because I explicitly ask for high 
precision if I need it.

If the compiler using or not using a higher precision magically fixes an 
actual issue with accumulated errors, that means the correctness of the 
code is dependent on something hidden, that you are not aware of, and 
that could break any time, for example at a time when you really don't 
have time to track it down.

> Reduced precision is only useful for storage formats and increasing
> speed.  If a less accurate result is desired, your algorithm is wrong.

Nonsense. That might be true for your use cases. Others might actually 
depend on IEE 754 semantics in non-trivial ways. Higher precision for 
temporaries does not imply higher accuracy for the overall computation.

E.g., correctness of double-double arithmetic is crucially dependent on 
correct rounding semantics for double:
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic

Also, it seems to me that for e.g. 
https://en.wikipedia.org/wiki/Kahan_summation_algorithm,
the result can actually be made less precise by adding casts to higher 
precision and truncations back to lower precision at appropriate places 
in the code.

And even if higher precision helps, what good is a "precision-boost" 
that e.g. disappears on 64-bit builds and then creates inconsistent results?

Sometimes reproducibility/predictability is more important than maybe 
making fewer rounding errors sometimes. This includes reproducibility 
between CTFE and runtime.

Just actually comply to the IEEE floating point standard when using 
their terminology. There are algorithms that are designed for it and 
that might stop working if the language does not comply.

Then maybe add additional built-in types with a given storage size that 
additionally /guarantee/ a certain amount of additional scratch space 
when used for function-local computations.