Re: the Endian issue in interchange formats
P-1788,
I invite discussion on this issue, simultaneous with the voting.
In particular, does anyone object to completely specifying
the interchange format by specifying the endian-ness of the
constituent numbers
(as is done in the version of the P-1788 document now under vote)?
(If there are no objections, there will be some minor clarifying
changes to the document. If there are objections, we will proceed
to another vote.)
Baker
On 06/17/2014 12:52 PM, Michel Hack wrote:
I vote YES on Motion M0062: Accept the document.
After several hours of reading the June 10 version of the document, I
spotted a couple of editorial nits and typos -- and one unanticipated
change that may need more serious consideration.
.
.
.
Now to my more serious concern, page 64, and consequences for page 87:
We have suddenly become more prescriptive than 754-2008 with regard
to interchange encoding! Was this intentional? If so, we should
say it clearly, and revise the sentence at the end of the first
paragraph of 14.4: "delegating interchange encoding of number
datums to the IEEE 754 standard".
That's because 14.4 prescribes the entire bitstring representation of
an interval as Big Endian (or, perhaps more diplomatically, Network
Byte Order): "The first bit is the sign bit and the last bit is the
least significant bits (LSB) of the significand." (Typo: bits -> bit)
If we leave Endianness unspecified (as 754-2008 does), this description
conflicts with the ordered triple description, where inf(x) and sup(x)
are the natural encodings of the 754 format (e.g. binary64), which on a
Little-Endian machine have the eight bytes in the opposite order. We
can of course not see bit order (except on a serial transmission medium,
which is waaay beyond the scope of these standards), but byte order *is*
an issue.
I think it was a good idea to describe the entire (2n+1)-byte object as an
ordered bitstring, and would just add explicitly that "the bytes are to be
in Network Byte Order". But we must then change the description in terms
of a triple of two 754-objects and a one-byte decoration, and point out
that the byte order of the entire interchange-format object is prescribed
(which goes beyond what 754 prescribes).
The distinction is in fact important, when you consider the exchange of
multiple interval objects.
Of course, if this was NOT the intent, we have to rewrite the description
in terms of an ordered concatenation of two 754-objects and a decoration
byte, and remove the bitstring details.
Page 87, C 6.2, Interchange representations (for the Basic Standard), is
slightly different. It actually says that "the b64 datums are encoded as
in the IEEE 754 interchange format" -- but the example is definitely for
a Big-Endian representation, without mentioning this explicitly. It too
needs changes, once we decide exactly what the intent was.
Baker and George, this is a substantial issue, and I'm not quite sure how
to proceed at this stage.
Michel.
---Sent: 2014-06-17 17:56:30 UTC
--
---------------------------------------------------------------
Ralph 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
---------------------------------------------------------------