Motion P1788/M0029.01: Level-3-interface-only --- Final version to vote on
P1788
I have accepted various comments during the discussion period as friendly amendments, and I post herewith what I hope will be the final version of Motion 29 that we will vote on. However, Chair, before announcing the voting period will you leave a short time for the relevant people to check that my amendments correctly reflect their concerns?
To make the changes clear, I have hard-wrapped the text and then put change-bars on lines I have edited.
The postings that are most relevant to these changes are:
- Dan Zuras, 18 November 2011 20:13:48 GMT.
- Nate Hayes, 19 November 2011 14:33:27 GMT and following discussion
between Nate, Lee Winter and Michel Hack. I may not have grasped the
finer subtleties of this.
- Michel, 19 November 2011 20:23:27 GMT, see also Ulrich Kulisch, Dan and Nate.
- Ian McIntosh, 18 November 2011 20:44:43 GMT. However, Ian, I do not see how
this motion impacts on efficiency of implementation.
Regards
John Pryce
Motion 29
=========
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 type shall be defined at the bit level, for
| _available_ or _supported_ 754-conforming interval 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 type.
(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.
| However the interchange type here specified is a platform-independent binary
| form, not intended to be human-readable. The aim is that it should be trivial
| to convert between it and any reasonable internal type that represents the
| same intervals. Passing this motion does not imply that the Level 3 internal
| form of such an inf-sup type need represent [xlo,xhi] by the pair (xlo,xhi) --
| the pair (-xlo,xhi) might be popular, for well-known reasons -- nor that it
| need represent Empty by two NaNs.
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 any floating point format that conforms to the definitions in
| IEEE754 clause 3, in any radix and any precision, and whether supported
| as an arithmetic or an interchange format by the underlying system.
| That is, the nonempty members of T comprise all intervals xx=[xlo,xhi],
| where xlo and xhi are F-numbers, excluding the cases where they are infinite
| and of the same sign. Such interval types shall 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 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.
! The following issues are deferred to a later motion. Items b,c are relevant
! to, among other things, specifying an interchange format for Compressed
! (decorated) Intervals -- the proposed type that stores a bare interval,
! or a bare decoration, but not both at once, in the same number of bits as
! a bare interval.
! a. Is bits(x) canonicalized, e.g. is 0 always represented as +0?
! b. Are payloads of NaNs preserved on writing and reading?
! c. What meanings, if any, are specified for bits(NaN) + bits(x) or
! bits(x) + bits(NaN), where x is an F-number, not NaN?