[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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"
         here too?


P.S.  I repeat my question about tomorrow.  Is there a style review?
Sent: 2006-09-18 19:26:54 UTC

754 | revision | FAQ | references | list archive