Re: Motion: No level 3-4 stuff except interchange format
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Subject: Motion: No level 3-4 stuff except interchange format
> Date: Fri, 18 Nov 2011 16:05:30 +0000
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> 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.
Let me suggest that you generalize F to any supported
(in the 754 sense) format rather than limit yourself to
just the first five. There are two reasons for this.
First, everything you are asking of a 754 format is also
provided in any format (including those of arbitrary
precision) that is supported as 754 defines supported.
And, second, including those more general formats may
(someday soon) bring along all those in the interval
community who work with arbitrarily high precision.
>
> 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.
This is good. I believe (& it is just my opinion) that
an implementation has far fewer problems if it sticks
to one radix. My favorite is binary but your mileage
may vary.
>
> 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.
All supported 754 formats (even beyond the first 5)
are required to have an interchange format for just
this purpose.
But let me suggest that we not define the nature of
empty internally. And, for our purposes, the string
that represents the interchange for an empty interval
can be something like "empty". No need to let the
user peek into the box more than is required.
>
> 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.
All this is good. I would second a motion written
along these lines. Especially with the generalizations
I have suggested.
Dan