On Dec 3, 2006, at 12:44, Kaveh R. GHAZI wrote:
In case i370 support is revived or a format not using base==2 is
introduced, I could proactively fix the MPFR precision setting for any
base that is a power of 2 by multiplying the target float precision by
log2(base). In the i370 case I would multiply by log2(16) which is 4.
When base==2, then the log2(2) is 1 so the multiplication
simplifies to
the current existing behavior.
That would not be correct, as the actual precision in bits of
a base==16 floating-point number depends on the magnitude of the number.
The gaps between adjacent hexadecimal floating-point numbers can be
2, 4 or 8 times that of binary floats with a mantissa of the same
number of bits (including any implicit leading 1's).
Example: In a floating-point format with 24 binary digits, the even
integers 0x1000002 through 0x100000e would be representable, while
a system with 6 hexadecimal digits there would be a gap between
0x1000000 and 0x1000010.
So, while the sum 16777216.0 + 2.0 does not depend on rounding
direction in IEEE single precision math, it would depend on
rounding direction for the IBM 370's single precision type.
For GCC's purpose, it seems that hexadecimal floating-point systems
can be regarded as a historical curiosity and adding significant
complexity for supporting some optimizations for them seems not
worth the distributed cost of maintenance. For IBM 370 math, we
should always either:
- call library functions for evaluation
- convert to IEEE, operate, convert back
-Geert
