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.
