RFC getting at the bits of {L} real

[chris hermansen]

Good afternoon, everyone,

I would like to get comments from anyone interested on the issue of
getting at the bits of {L} real.

First, I am assuming that most current CPU architectures support IEEE
754 floating point.  I know that the IBM S390 C compiler allows
selection of the representation - either IEEE 754 or "hexadecimal
floating point" (though according to this page

https://www.ibm.com/docs/en/zos/3.2.0?topic=point-cc-compiler-support

this is only since Release 6 of OS/390).

Are there any known targets of GCC that do not support IEEE 754?

Second, and perhaps in any case, {L} real (and {L} compl) are somewhat
"opaque", in the sense that we don't have a standard way to get at the
exponent and significand of the number without resorting to a lot of
arithmetic, which - at least if done poorly - can introduce
imprecision or error when converting between external string
representations and internal binary representations.

As for IEEE 754 format floating point, there are recent formal
conversion routines such as Dragonbox and Schubfach that attempt to
convert - very efficiently - between external string and internal
binary representations in such a way that numbers "survive" the round
trip with no introduced error and that the external representation is
as short as it can be without introducing error.

As far as I can tell, Java's Float::toString and Double::toString have
moved in this direction, and there are some implementations of these
algorithms in Rust, C++ and C "out there"; whether they are moving
into the core or not, I cannot say.

Here is an interesting and brief read about this:

https://bugs.openjdk.org/browse/JDK-4511638

The transput routines fixed and float specified in the RR handle the
conversion using logarithms, multiplying and dividing and include the
use of numbers such as 0.1 that don't have exact IEEE 754 binary
representations.  I don't believe there is a proof of correctness,
brevity or accuracy for either of these.  I doubt their ability to
round-trip.  Also they are computationally costly.

In sum, I think there is a decent case to be made for a more modern
and rigorous implementation of proc fixed and proc float.

Such implementations would benefit by being able to directly access
sign, exponent and significand bit patterns.

At least as far as IEEE 754 floating point implementations go, I think

op BIN = (real x) bits: { however this might be done };
op BIN = (long real x) long bits: { however this might be done };

could be really useful.  This leaves out long long real which as far
as I understand is implemented as the Intel "extended floating point"
type, an 80-bit representation, so that

op BIN = (long long real x) long long bits

would not work.

Some time ago, Jose suggested instead returning a triple

struct {int sign, int exponent, long int significand)

which could work in all cases.

Should some architecture use IEEE 754 quadruple precision for long
long real, then we would need a long long int type of at least 112
bits to hold the significand.

Any thoughts on the foregoing?

In the medium term at least, we can stick with the existing proc fixed
and proc float.
-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.