On Wednesday, 23 October 2013 at 16:50:52 UTC, Walter Bright
wrote:
On 10/23/2013 9:22 AM, David Nadlinger wrote:
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright
wrote:
A D compiler is allowed to compute floating point results at
arbitrarily large
precision - the storage size (float, double, real) only
specify the minimum
precision.
This behavior is fairly deeply embedded into the front end,
optimizer, and
various back ends.
I know we've had this topic before, but just for the record,
I'm still not sold
on the idea of allowing CTFE to yield different results than
runtime execution.
Java initially tried to enforce a maximum precision, and it was
a major disaster for them. If I have been unable to convince
you, I suggest reviewing that case history.
Back when I designed and built digital electronics boards, it
was beaten into my skull that chips always get faster, never
slower, and the slower parts routinely became unavailable. This
means that the circuits got designed with maximum propagation
delays in mind, and with a minimum delay of 0. Then, when they
work with a slow part, they'll still work if you swap in a
faster one.
FP precision is the same concept. Swap in more precision, and
your correctly designed algorithm will still work.
THIS IS COMPLETELY WRONG. You cannot write serious floating-point
code under such circumstances. This takes things back to the bad
old days before IEEE, where results were implementation-dependent.
We have these wonderful properties, float.epsilon, etc, which
allow code to adapt to machine differences. The correct approach
is to write generic code which will give full machine precision
and will work on any machine configuration. That's actually quite
easy.
But to write code which will function correctly when an
unspecified and unpredictable error can be added to any
calculation -- I believe that's impossible. I don't know how to
write such code.
