Remove real type

[BCS]

Hello bearophile,

> I suggest to remove the real type from D2 because:
 
> - Results that you can find with programs written in other languages
> are usually computed with just floats or doubles. If I want to test if
> a D program gives the same results I can't use reals in D.

You can if you include error bounds. IIRC the compiler is free to do a lot 
of optimizations and for FP, that can result in inexact matches (keep in 
mind that some (or is it all) FPUs do ALL internal math in 80bit so what 
intermediate values if any are converted through 64/32bit can make a difference 
in the result even for the other types) so you can't even avoid error bounds 
on doubles or floats.

> - I don't see reals (long doubles in C) used much in other languages.

It can be asserted that this is a result of them not being easy to use.

> Five or ten years from now most numerical programs will probably not
> use 80 bit FP.

That depends on what they are doing. People who really care about accuracy 
will only dump 80bit FP for 128bit FP (quad).

> - I have used D1 for some time, but so far I have had hard time to
> find a purpose for 80 bit FP numbers. The slight increase in precision
> is not so useful.

How much hard core number crunching do you do?

> 
> - D implementations are free to use doubles to implement the real
> type. So in a D program I can't rely on their little extra precision,
> making them not so useful.

No, a conforming D implementation *must* implement real with the largest 
HW FP type available.

> - The D2 specs say real is the "largest hardware implemented floating
> point size", this means that they can be 128 bit too in future. A
> numerical simulation that is designed to work with 80 bit FP numbers
> (or 64 bit FP numbers) can give strange results with 128 bit
> precision.

Can use support that? Aside from a few cases where you are effectivly bit 
twiddling, code designed to run in 80bit should work at least as well with 
128bit.

> 
> So I suggest to remove the real type; or eventually replace it with
> fixed-sized 128 bit floating-point type with the same name
> (implemented using a software emulation where the hardware doesn't
> have them, like the __float128 of GCC:
> http://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html ).
> 
> In far future, if the hardware of CPUs will support FP numbers larger
> than 128 bits, a larger type can be added if necessary.

I think that real should be keep as is. Most of your points can be addressed 
by adding a new type that is defined to be the current 80bit type. That way, 
if the programer want to force a given size, they can, and if they just want 
the biggest type they can get they can do that as well.

-- 
... <IXOYE><