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

[Don]

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.