GDC release 0.23

[Anders F Björklund]

Don Clugston wrote:

>> Might as well keep the real <-> long double one-to-one mapping, and
>> recommend *not* using real/ireal/creal types for any portable code ?
> 
> No, that does not work. double is *not* portable!
> I'll say it again, because it's such a widespread myth: **double is not 
> portable**. Only about 20% of computers world-wide have native support 
> for calculations at 64-bit precision! More than 90% have native support 
> for 80-bit precision.
> (The most common with 64-bit precision are PPC and Pentium4. Earlier 
> Intel/AMD CPUs do not support it).

The actual suggestion made was to make "real" into an *alias* instead.

That is, you would have one type "extended" that would be 80-bit
(and not available* on PowerPC/SPARC except with software emulation)
and one type "double" that would be 64 and one type "float"/32...

Then "quad" could be reserved as a future keyword for IEEE 128-bit,
just as "cent" is reserved for 128-bit integers. (it's not important)
Using extended precision floats on Intel is not a bad thing at all.

I think we agree that using double on X86 (or long double on others)
isn't optimal, because of the round-off (or even missing exceptions).
So you probably will need different types on different architectures.

But as it is now, "real" in D is the same as "long double" in C/C++.
So you would have to make a new alias for the D floating point type,
and then alias it over to real on X86 and to double on the others ?

Or perhaps use "float" instead, for vectorization opportunities ? :-)

--anders

* not available or using double-double, it doesn't matter much ?
   software emulated or not fully IEEE, either way not for "real"
   (i.e. the "largest hardware implemented floating point size")