Comments on draft 1.2.1 of 17 Sept 2006 (really, this time)
In my earlier mail I thought I was commenting on 1.2.1 (which was
displayed on my screen), but I prefer working with paper, and printing
draft 1.2.1 resulted in a copy of 1.2 for still-murky reasons. So let
me try again, taking Jeff Kidder's correction into account.
Page 14, 3.2.32 radix: This one should mention floating-point data (not
numbers), as the radix also applies to the representation of
NaNs (the payload).
(Page 17 -- typos fixed in 1.2.1)
Page 36, 7.8: Several unresolved issues, some of which (e.g. Jim's
question about "supported") I thought we had dealt with,
and some which I've brought up repeatedly, namely the
rewording of Invalid handling to reflect the changes
in 9.2 that were accepted at our last full meeting.
The suggested fix is different, now that I have seen the new 9.2
that clarifies this issue. The paragraph that mentions overflow
should simply be replaced with the following two paragraphs:
When a NaN operand cannot be represented in the destination
format and this cannot otherwise be indicated, the invalid
exception shall be signalled.
When a numeric operand would convert to an integer outside the
range of the destination format, the invalid exception shall
be signalled if this situation cannot otherwise be indicated.
Page 42, 7.12.3, typo in line 2 of the revised 1st para: and -> an
(I see that Jim's motion *was* integrated.)
Page 47, 9.2 2nd para: Ok in 1.2.1 (and better than before)
Page 47, 9.2 j): should be "floating-point datum", as NaN is included
(and indeed mentioned in the same sentence).
Page 47, 9.2 l), logBFormat: this sentence does not read right in 1.2.1
either. How about:
l) when logBFormat is an integer format, and the operand
of logB() is a NaN, infinity, or zero (see 7.3.3).
I see that appendix G (formerly F) *was* updated in 1.2.1 -- a bit more
than I'm comfortable with, actually, in that I'm not sure now whether
the intent was violated.
Page 60, last para of G.3 Numerical Exceptions. I still think that the
second sentence could be made clearer as follows:
Consequently it should be possible to request that bitwise
operations like negate, abs, and copySign, which are
normally silent, should detect signalling NaNs.
In the 3rd sentence, the addition of the word "signalling"
completely changes the meaning. I'm pretty sure Prof. Kahan
wanted the ability to make qNaNs behave like sNaNs, and not
the other way around (as it now reads).
Page 60, 1st para of G.4 Programming errors. Ok, the offending sentence
was removed, but I wonder now whether a replacement was needed,
as the preceding sentence says the same thing. (I may have been
responsible for the replacement sentence.)
Page 60, last para of G.4 Programming errors (and last of document).
I see that "pointers" have been replaced with "references" in
G.3, so perhaps "point to" could be replaced with "reference"
P.S. I repeat my question about tomorrow. Is there a style review?
Sent: 2006-09-18 19:26:54 UTC