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

[Apollo Hogan]

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.

There are a couple of points here:

- it seems that whatever the semantics of floating-point 
arithmetic, they should be the same at compile-time as at 
run-time.

- I agree that the majority of floating point code is only 
improved by increasing the working precision.  (If we don't worry 
about reproducibility across compilers/machines/etc.)  The "real" 
data-type seems to be designed exactly for this: use "real" in 
numerical code and the compiler will give you a good answer at 
the highest performant precision.  However there _are_ cases 
where it can be very useful to have precise control of the 
precision that one is using.  Implementing double-double or 
quadruple-double data types is an example here.   Viewing D as a 
_systems_ language, I'd like to have the ability to just have it 
do what I ask (and being forced to go to assembler seems 
unreasonable...)

Anyway, thanks for the replies.  I guess I've got to go off and 
design the brand new D^^2 language to conform to my whims now.

Cheers,
--Apollo