This might imply increased precision on SPARC boxes
In many instances the 16 byte long double provides the same (64-bit) precision as the 12 byte variant ... and the same exponent range, too, I think.
But it's the double-double arrangement that enables contrived comparisons (such as the one I provided) to work.
It would take a data type providing 663 bits of precision to detect that 1.0 + 5e-200 > 1.0, whereas the double-double arrangement of the PowerPC long double stores 1.0 in one double and 5e-200 in the other. The processor then knows that the sum of both is greater than either of the 2 doubles because both doubles are positive and non-zero.
At least, that's how I surmise.
The processor cannot detect that 1.1 + 5e-200 > 1.1 because the "1.1" value gets written over both doubles - and adding 5e-200 then makes no difference to the 2 stored double values.
I was hoping that a printf "%.200Le", ... of the 1.0 + 5e-200 value might print out the actual value of 1.00000...005 but, alas, doesn't even get close (in perl or C).
BTW, the "bitch" part is that, with certain values, you can get rounding errors if you try to print out more than 15 decimal digits of precision (in perl or C).
All in all, an intriguing arrangement - and one that almost works beautifully.
Cheers, Rob | [reply] [Watch: Dir/Any] [d/l] [select] |
From what I know about the x86 long double is that, for PPC, I guess sizeof is returning 16 for alignment reasons. 12 is the actual used portion. A long double is 80 bits/10 bytes on x86. Mingw claims it is 12 bytes in a sizeof.
| [reply] [Watch: Dir/Any] |
for PPC, I guess sizeof is returning 16 for alignment reasons
With PPC, it actually uses the 16 bytes (in the form of 2 8-byte doubles).
There are other processors that use 12 bytes but assign 16 bytes (for alignment purposes, as you said).
Cheers, Rob
| [reply] [Watch: Dir/Any] |