On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright
wrote:
On 10/30/2013 6:50 AM, Don wrote:
Unpredictable, sure, but it is unpredictable in that the
error is less than a
guaranteed maximum error. The error falls in a range
0<=error<=epsilon. As an
analogy, all engineering parts are designed with a maximum
deviation from the
ideal size, not a minimum deviation.
I don't think the analagy is strong. There's no reason for
there to be any error
at all.
Besides, in the x87 case, there are exponent errors as well
precision. Eg,
double.min * double.min can be zero on some systems, but
non-zero on others.
This causes a total loss of precision.
If this is allowed to happen anywhere (and not even
consistently) then it's back
to the pre-IEEE 754 days: underflow and overflow lead to
unspecified behaviour.
The idea that extra precision is always a good thing, is
simply incorrect.
Not exactly what I meant - I mean the algorithm should be
designed so that extra precision does not break it.
Unfortunately, that's considerably more difficult than writing an
algorithm for a known precision.
And it is impossible in any case where you need full machine
precision (which applies to practically all library code, and
most of my work).
The problem is that, if calculations can carry extra
precision, double rounding
can occur. This is a form of error that doesn't otherwise
exist. If all
calculations are allowed to do it, there is absolutely nothing
you can do to fix
the problem.
Thus we lose the other major improvement from IEEE 754:
predictable rounding
behaviour.
Fundamentally, there is a primitive operation "discard extra
precision" which is
crucial to most mathematical algorithms but which is rarely
explicit.
In theory in C and C++ this is applied at each sequence point,
but in practice
that's not actually done (for x87 anyway) -- for performance,
you want to be
able to keep values in registers sometimes. So C didn't get
this exactly right.
I think we can do better. But the current behaviour is worse.
This issue is becoming more obvious in CTFE because the extra
precision is not
merely theoretical, it actually happens.
I think it's reasonable to add 3 functions (similar to peek and
poke) that force rounding to float/double/real precision. By
inserting that into the code where the algorithm requires it
would make it far more clear than the C idea of "sequence
points" and having no clue whether they matter or not.
Yeah, the sequence points thing is a bit of a failure. It
introduces such a performance penalty, that compilers don't
actually respect it, and nobody would want them to.
A compiler intrinsic, which generates no code (simply inserting a
barrier for the optimiser) sounds like the correct approach.
Coming up for a name for this operation is difficult.
