Remove real type

[Eric Poggel]

On 4/21/2010 7:00 PM, Bill Baxter wrote:
> 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
>>

Just a personal preference, but I always disliked "secret" features of 
languages hidden behind underscores.  I feel like features should be 
part of the standard spec or not there at all.