Motion: No level 3-4 stuff except interchange format
P1788 members
There are some issues to do with Levels 2 onwards that we have never voted on, as far as I can see. I hereby submit a motion on these. Various aspects need discussion. Maybe it should be split in two. I will appreciate help to put it in a final form. And of course I need a second.
John Pryce
Motion
======
There is a positive part:
1a. There shall be a notion of _754-conforming_ interval type.
1b. Mixed-precision basic arithmetic operations shall be provided for _supported_ 754-conforming types.
1c. An _interchange format_ shall be defined at the bit level, for _available_ or _supported_ 754-conforming types.
Recall the supported/available distinction is from motion 16.
There is a negative part:
2. The standard shall say nothing at levels 3, 4, except to specify the above interchange format.
(And I/O from Motion 17, if that is counted as a Level 3 or 4 item.)
Rationale
=========
The notion "interval type" T is defined at Level 2 abstractly, essentially as a finite set of mathematical intervals, plus a hull function. We've put no requirements on how an implementation represents T-intervals internally, and I see no reason to do so.
We decided there shall be ways to write T-intervals to a human-readable text representation, and read these back (Motion 17). This includes a text representation that is faithful in the sense that it is possible to read it back to recover the original internal T-interval. That gives one method for interchange between platforms.
I defined a 754-conforming type long ago but we haven't voted on the idea. It is the case where
T is an inf-sup type derived from a number format F
and F is one of the five basic IEEE754 formats binary32, binary64, binary128, decimal64, decimal128. That is, the nonempty members of T comprise all intervals xx=[xlo,xhi], where xlo and xhi are F-numbers. I propose these 5 types be called the _754-conforming_ types.
My original reason to make them special was because it is easy to specify mixed-precision arithmetic operations on them using 754's corresponding "formatOf" floating-point operations. Specifically
zz = xx op yy
is provided where xx, yy, zz may have different 754-conforming types but must have the same radix. In earlier draft text I called these "Single Radix Multiple Format", SRMF, operations.
However they also support an interchange medium at the binary level. One can't specify this for a "general" T assuming only what's in the Explicit/Implicit motion 19, but for each 754-conforming type we can easily define its interchange format (should it be "interchange type"?) as follows:
- Nonempty xx=[xlo,xhi] is represented by bits(xlo) + bits(xhi).
- Empty xx is represented, say, by bits(NaN) + bits(NaN).
Here bits(x) is the bit-string of an F-number x (as described in the 754 standard), and + means concatenate.
The resulting bit-string, call it interchange(xx), is to exist at a level above details like whether the machine is big- or little-endian, so we ignore those.
One must decide various things such as: Is bits(x) canonicalized, e.g. is 0 always represented as +0? And are payloads of NaNs preserved on writing and reading? But basically the idea is simple.