Remove real type

[Bill Baxter]

I don't find it that useful either.  Seems to me the only use is to
preserve a few more bits in intermediate computations.  But finite
precision is finite precision.  If you're running up against the
limitations of doubles, then chances are it's not just a few more bits
you need -- you either need to rethink your algorithm or go to
variable precision floats.
Maybe just rename 'real' to something less inviting, so that only the
people who really need it will be tempted to use it.  Like __real or
__longdouble, or __tempfloat or something.

--bb

On Wed, Apr 21, 2010 at 3:38 PM, bearophile <bearophileHUGS at lycos.com> wrote:
> I suggest to remove the real type from D2 because:
> - It's the only native type that has not specified length. I'm sold on the usefulness of having defined length types. Unspecified length types causes some of the troubles caused by C types that D has tried to avoid defining the size of its integral types.
> - Its length is variable across operating systems, it can be 10, 12, 16 bytes, or even just 8 if they get implemented with doubles. The 12 and 16 bytes long waste space.
> - 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.
> - I don't see reals (long doubles in C) used much in other languages.
> - If I compile a program with LDC that performs computations on FP values, and I take a look at the asm it produces, I can see onl SSE-related instructions. And SSE registers allow for 32 and 64 bit FP only. I think future AVX extensions too don't support 79/80 bit floats. GPUs are increasingly used to perform computations, and they don't support 80 bit floats. So I think they are going to be obsolete. Five or ten years from now most numerical programs will probably not use 80 bit FP.
> - Removing a built-in type makes the language and its manual a little simpler.
> - 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.
> - 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.
> - While I think the 80 bit FP are not so useful, I think Quadrupe precision FP (128 bit, currently usually software-implemented) can be useful for some situations, (http://en.wikipedia.org/wiki/Quadruple_precision ). They might be useful for High dynamic range imaging too. LLVM SPARC V9 will support its quad-precision registers.
> - 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.
>
> 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.
>
> Bye,
> bearophile
>