I was reading the infamous JAVAHurt paper over,
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

and found some words on it, describing the various
floating-point types that I was trying to talk about...


From the JAVAhurt paper:
> Names for primitive floating-point types or for Borneo floating-point classes:
> 
> float = 4-byte IEEE 754 Single with 24 sig. bits, usually hardware supported.
> double = 8-byte IEEE 754 Double with 53 sig. bits, usually hardware supported.
> long double = 10+-byte IEEE 754 Double Extended with at least 64 sig. bits etc.
> 
> { longdouble(k) = k-byte IEEE 754 Double Extended ( for future use only with k >> 10.)
>   quadruple = long double(16) with 113 sig. bits rounded as IEEE 754/854 requires.
>   DoubledDouble = 16-bytes with at least about 106 sig. bits perhaps rounded perversely. }
> 
> indigenous = the widest floating-point format supported in hardware at full speed
>   = long double = double extended on hardware that does it
>   = double on computer hardware that does nothing wider.

This "indigenous" is the same as the "long double" in C and "real" in D.
I was suggesting to re-introduce "extended" for the third type above...


DoubledDouble would be the -mlong-double-128 option that IBM AIX has.
See http://www.linuxbase.org/spec/ELF/ppc64/PPC-elf64abi-1.7.html#PREC
has all the details on what Prof. Kahan calls a "perverse format" :-)

Quadruple would be a future actual 128-bit type, that no-one has now.
(and probably won't appear until we see 128-bit integer CPUs, or so?)
Note: Maybe we want to reserve this as a new type, just like "cent" ?


I thought that "real" was a perfect fit for an alias, since it's
actually referring to one of two types - depending on hardware ?

DoubledDouble is unusable in D due to lack of nan/inf and all traps,
and Quadruple is not available yet. Leaving only Extended and Double.

And, last but not least, the suggestion also "fixed"
http://www.digitalmars.com/d/archives/28044.html :

... "sorry, but with these names for complex and imaginary numbers,
you have created a joke among mathematicians for the years to come!"



And then, a second concern, is the alignment size of such a "real"...
There seems to be several possible values for this too, unfortunately.

- Double => 8-byte / 64-bit alignment (natural)
- old Windows "long double" => 10-byte / 80-bit alignment (unpadded)
- X86 Linux "long double" => 12-byte / 96-bit alignment (word aligned)
- X86_64 Linux "long double" => 16-byte / 128-bit alignment (Pentium+)

So to support linking with C functions, all *four* types must be used ?
Otherwise, a natural choice for native D alignment would be 128 bits ?

--anders