Mark Dickinson <dicki...@gmail.com> added the comment:
Would it be acceptable to use shorter float repr only on big-endian and
little-endian IEEE 754 platforms, and use the full 17-digit repr on other
platforms? This would greatly simplify the adaptation and testing of
Gay's code.
Notable platforms that would still have long repr under this scheme, in
order of decreasing significance:
- IBM zSeries mainframes when using their hexadecimal FPU (recent
models also have IEEE 754 floating-point, and Linux on zSeries
uses that in preference to the hex floating-point).
- ARM, Old ABI (uses a mixed-endian IEEE 754 format; a newer set
of ABIs appeared recently that use big or little-endian IEEE 754)
- Cray SV1 (introduced 1998) and earlier Cray machines. Gay's code
doesn't support the Cray floating-point format anyway. I believe
that newer Crays (e.g., the X1, introduced in 2003) use IEEE
floating-point.
- VAX machines, using VAX D and G floating-point formats. More recent
Alpha machines support IEEE 754 floats as well.
- many ancient machines with weird and wonderful floating-point
schemes
As far as I can determine, apart from the IBM machines described above all
new platforms nowadays use an IEEE 754 double format. Sometimes IEEE
arithmetic is only emulated in software; often there are shortcuts taken
with respect to NaNs and underflow, but in all cases the underlying format
is still IEEE 754, so Gay's code should work. Gay's careful to avoid
problems with machines that flush underflow to zero, for example.
Gay's code only actually supports 3 floating-point formats: IEEE 754 (big
and little-endian), IBM hex format and VAX D floating-point format. There
are actually (at least?) two variants of D floating-point: the version
used on VAX, which has a 56-bit mantissa and an 8-bit exponent, and the
Alpha version, which only has a 53-bit mantissa (but still only an 8-bit
exponent); Gay's code only supports the former.
I'm quite convinced that the VAX stuff in Gay's code is not worth much to
us, so really the only question is whether it's worth keeping the code to
support IBM hexadecimal floating-point. Given the difficulty of testing
this code and the (significant but not overwhelming) extra complexity it
adds, I'd like to remove it.
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
