Motion M0062: YES
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.
First, the nits:
Page viii, there appear to be two unnumbered sub-bullets of 11.7
(decoration of non-arithmetic operations).
Page 10, 2nd para of 4.2.57 tightest:
denotes ones -> denotes one
Page 59, 3rd line of 12.13.5 Exact reduction operations:
capable to represent -> capable of representing
Page 63, middle of paragraph just above 14.3:
there is an unique NaN -> there is a unique NaN
Page 64, middle (see also below):
is the least significant bits -> is the least significant bit
Page 72, C2.2 Intervals, where "the whole real line" is mentioned,
say that this is also denoted by Entire.
(This is to make Chapter C self-contained; it is
needed in C2.5.1, Interval constants, on page 75.)
Page 79, 1st bullet in C3.3 The ill-formed interval:
can not -> cannot
Page 79, Note at the end of C3.5.2: I *think* we want FTIA -> FTDIA
*--------------*
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