Motion P1788/M0029.01: Level-3-interface-only --- discussion period begins
P-1788:
Since Motion 29 has been made by John Pryce and
seconded by Lee Winter, the discussion period now
begins, and will end after Friday, December 9, 2011.
I append the motion, along with John's original short
comment.
Discussion on this motion will proceed according to the rules for
position papers.
Juergen: Please place the motion and associated information
in the appropriate place on the web page, as
you have aptly done in the past.
Acting secretary: Please record the transaction in the minutes.
By the way, the explanation of what level 3 and level 4 are can be
found in section 3.1 and Table 1, page 10 of the working draft, at
http://grouper.ieee.org/groups/1788/private/TheP1788Document/P1788_MAIN.pdf
Basically, level 3 deals with the floating point system (mantissa
length, base, exponent length, etc.), while level 4 deals with bit
strings.
As usual, please contact me if you need the password to the private
area of the P-1788 web site.
Best regards,
Baker (acting as chair, P-1788)
On 11/18/2011 10:05 AM, John Pryce wrote:
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.
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------