GDC release 0.23

[Don Clugston]

Anders F Björklund wrote:
> 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.

OK. In many ways that would be better; in reality, when writing a math 
library, you always have to know what precision you're using.

> 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 ?

I think that could work. Although for the others, it might need to be a 
typedef rather than an alias, so that you can overload real + double 
without causing compilation problems? (I'm not sure about this). And you 
  want 'real' to appear in error messages.