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<bearophileh...@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.
