Re: Motion: No level 3-4 stuff except interchange format
> Date: Fri, 18 Nov 2011 21:18:48 -0600
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: John Pryce <prycejd1@xxxxxxxxxxxxx>, stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Motion: No level 3-4 stuff except interchange format
>
> Dan,
>
> The points you make are good. Since the motion has already been
> seconded, your input can be used as appropriate to amend the motion
> prior to the voting phase.
>
> Best regards,
>
> Baker
Thank you, Baker.
I am not so adamant about them as to override John's wish
to forward things that need forwarding. However, I will
offer them to John as a friendly amendment to be expressed
in any way he sees fit. Or not, as the case may be.
Dan
>
> On 11/18/2011 02:13 PM, Dan Zuras Intervals wrote:
> >> 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