Re: Interchange formats (was: NaI's as decorated empty sets)
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Interchange formats (was: NaI's as decorated empty sets)
> Date: Wed, 9 Sep 2009 15:06:21 +0100
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Michel and all
>
> On 9 Sep 2009, at 11:23, Michel Hack wrote:
> > Arnold Neumaier wrote:
> >> The standard should be silent about how things are actually
> >> represented, and only specify the effect of operations on
> >> the representations (whatever they are).
> >
> > Except for interchange formats -- if we want to deal with that.
>
> As far as I'm aware, this is the first time interchange formats for
> intervals have been mentioned. Seems to me this is a good idea, as it
> surely won't be too difficult, and will be found useful? ASSUMING, as
> seems likely, that we define level 3 representation to be a version
> of infsup form, I would suggest
>
> 1. Define interchange formats only for 754-conforming interval systems.
>
> 2. Have exactly one interval interchange format for each 754
> interchange format.
>
> 3. Define it basically to consist of the concatenated bit-strings of
> xlo and xhi where the level 3 representation of a nonempty interval
> is floating-point datums xlo, xhi representing the bounds.
>
> 4. If the implementation uses an [xlo, xhi] representation at level
> 3, then use the same scheme for Empty, and for any NaI's that may be
> defined.
>
> 5. But if the implementation uses a different representation, say [-
> xlo, xhi], we need to define some conventions for how this maps to
> the [xlo, xhi] form. Trivial for nonempty intervals, not quite so in
> the case of Empty and NaI's.
>
> Are there any other difficulties? Apart from endian-ness.
>
> John
John,
This seems like a good prescription for interchange.
A few things:
If an implementation uses [-xlo,xhi] instead of [xlo,xhi]
I believe it is still acceptable to ask it to do an
[-xlo,xhi] --> [xlo,xhi] conversion on interchange.
Their implementation still has an efficient local form
& the world has an intercahnge format that all will
recognise.
The issue of endian-ness was still up in the air in 1985.
There is mention of it in the 754 document (I forget just
where) but I believe it was placed outside the scope of
the document onto a memory standard. I seem to remember
it being 1596.5 but I can't be sure after all these years.
Similarly, I think 1788 will be able to punt this issue
as all modern computers have figured this one out for
ordinary data interchange.
Having a well defined interchange method also seems a
good complement to the Multi-format proposal of Motion 6.
Cool.
Dan