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
