Question/request/bug(?) re. floating-point in dmd

[Walter Bright]

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.


> 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.