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

Don x at nospam.com
Tue Oct 29 05:08:54 PDT 2013


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.






More information about the Digitalmars-d mailing list