Michel's comments on interchange representation
<Sorry, resending with improved Subject field. Discard previous.>
Michel
On 2014 Jun 17, at 18:52, Michel Hack wrote:
> 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.
>
> First, the nits:
I'll act on those as soon as I can.
> ...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)
I don't think this is such a substantive issue as you suggest. In discussions between Dmitry, Guillaume and me (also Juergen and Ned?) about this, I believe it was agreed that the bitstring specified by the interchange format is *conceptual* and endianness is to be never mentioned.
IMO the map between this and physical storage, defined by the hardware's endianness and possibly by the compiler, is a "Level 5" that is irrelevant to our standard. Yes, there are problems if one machine puts the bytes onto a serial medium in a different order from how another machine expects them but I don't think it's the standard's job to say how this should be solved.
Hence I think the solution is to explain the spec a bit better rather than to change it.
> ...
>
> 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.
Again, I think clarification rather than change is needed. Maybe also ensure the wordings of C6.2 is the same as, or at least closer to, that of 14.4.
Am I missing something crucial here?
John Pryce