Hack's recirculation ballot on P754 draft 1.6.0

[Michel Hack <hack@xxxxxxxxxxxxxx>]

Here is what I plan to post officially in a couple of days.  Perhaps
this will draw some comments that might improve the submission.

Editorial  5.2
P25 L32:  For quantize and roundToIntegralExact, the result is...

Technical  5.7.2
P32 L24, L26:  I think isCanonical() and isSignalling() should be
          provided for all formats (not just arithmetic), as the
          answer cannot portably be determined by first widening
          to an arithmetic format.  The problem is less acute for
          isNormal() and isSubnormal() because one can compare to
          limits.

General    5.7.2
P32 L38:  The only sensible translation-time predicate is radix().
          It is peculiar anyway because it does not depend on the
          value.  I wonder why there is no format() function instead
          that would return enum(binary32, binary64, ..., decimal128).

Technical  5.7.4
P33 L23:  Old concern (already voiced for 1.5.0 and perhaps earlier):
              What does restoreFlags(saveFlags(group1), group2) mean
              when group1 differs from group2 -- especially if the
              intersection is empty?

              I think it should say "when exceptionGroup matches".

Editorial  5.12.2
P40 L12:  Sentence is wrong (this should have been noticed earlier!)

          should say: "...given: the directed rounding error has the
                       correct sign in all cases, and never exceeds
                       1.001 units in the last place in magnitude."

Editorial  7.6
P46 L25:  incomplete cross-reference.

          Make it:  "(see 9.1.1 and 9.4)"


Technical  7.6
P46 L25+: The definition of Inexact on lines 22-24 does not cover
          quantize() and roundToIntegralExact(), whose result would
          be unchanged were both exponent range and precision unbounded.
          I suggest adding:

             "In addition, the inexact exception shall be signalled
              for quantize and roundToIntegralExact when the result
              value differs from the source value."

Editorial  8.2
P48L1-7:  Wrong indentation; this is a continuation of "abruptUnderflow".
          It would in fact be nice to repeat the bullet header, perhaps
          in parentheses, or use a "keep" to prevent the bullet text
          from being split across pages.  (I remember text processing
          systems from the 1970s and 1980s that had no trouble with this.)

Editorial  9.2
P52 column 4 for atan: remove xref; 9.2.1 does not have anything to say
            about exceptions for atan (only for atan2).

Editorial  9.2.1
P53 L23:  the range cannot be a closed interval (square brackets) if Pi
          is mentioned; the boundary points are either +-P1 or +-P1'
          where P1 is Pi rounded towards zero, and P1' is Pi rounded
          away from zero.  It would be nice to know which one it is.

          One way out would be to add the sentence:

            "The ranges mentioned below are for the named mathematical
            function; actual ranges are the corresponding rounded values."

Editorial  9.2.1
P53 L26-36:  same problem for all those mentions of Pi.  At the very
          least it should use a notation (e.g. PiR, for "Pi rounded"),
          though that is tricky for decimal formats (where round(Pi/4)
          may differ from round(Pi)/4 -- I ought to check this).

          Could benefit from the fix suggested for Line 23.

** Comment -- not part of proposed submission **
| P55 -- reductions:  MANY problems, though it is better than 1.5.8
|           and 1.5.9 (I was in contact with MFC on this).
|
|           I would really like to know what the intent of the BRC
|           was on some of these issues, so I know whether to make
|           an Editorial or a Technical comment.
|
| (1)  It is clearly REQUIRED now that the entire vector be scanned
|      for NaNs (or Infinities, in the case of sumSquare and sumAbs).
|      It may be worth mentioning that explicitly.  (The words "short-
|      circuit evaluation" were used in earlier drafts, I think.)
|
|      Short-circuit evaluation may still be possible after that pre-scan.
|      If no pre-scan is done, and a short-circuit opportunity presents
|      itself, whatever exception that was may have to be undone after
|      scanning the remaining operands to see if there is an override.
|
| (2)  Signalling NaNs are treated as Quiet.  This is a rather significant
|      deviation from the usual rules and should therefore be pointed out
|      explicitly -- unless that was NOT the intent (my guess).
|
| (3)  Either Infinity or NaN prevails, depending on the operation.
|      (There seems to be a precedent with the hypot() function.  Should
|      that be revised, these sum reductions should be revised too.)
|
| (4)  The text is of two minds with respect to Inexact; this may be an
|      oversight, and perhaps Inexact was to be mentioned together with
|      overflow and underflow as implementation-dependent (P55 L17).
|
| The sum reduction description includes this final step of converting
| the intermediate overflow-proof sum to the target format.  It is not
| entirely clear whether P55 L16 implies that Inexact should be based
| on this one operation, or whether it applies to the entire reduction.
| Even so, it is "if" and not "if and only if".  I suspect the intent is
| that overindication is permitted, but perhaps that should be explicit.
|
| In any case, in any practical implementation Inexact will depend on
| the implementation (as the intermediate width is not specified), and
| so will not be "identical" (P55 L18).


Technical  9.4
P55 L7   Assuming the intent is to require examination of the entire
         vector, Signalling NaN precedence should be re-affirmed, as
         the current text suggests that SNaNs may be treated as quiet.

         Add paragraph preceding the one starting on line 7:

           "If any operand is a signalling NaN, Invalid operation
           shall be signalled.  Otherwise:"

Technical  9.4
P 55 L 12  Text is not clear about Inexact, but correct Inexact could
         be so expensive that I assume this was not intended.  Hence
         clarify:

         Add parenthetical note:  "(Inexact may be overindicated.)"

Technical  9.4
P 55 L 17  Assuming Inexact overindication is permitted, add this to
         to overflow and underflow:

         Change "overflow, and underflow"
         to "overflow, underflow, and inexact"

         Alternatively, drop lines 17 and 18 entirely.  Those "other
         exceptions" boil down to Invalid and divideByZero, and the
         latter never applies here, so it's really just a matter of
         requiring a definite reproducible Invalid exception.  Now,
         I know that Invalid is one of the "reproducible" exceptions,
         but only for reproducible operations, and that does not
         include the reductions.  So what's the point?

Technical  9.4
P55 L37  Assuming the intent is to require examination of the entire
         vector, Signalling NaN precedence should be re-affirmed, as
         the current text suggests that SNaNs may be treated as quiet.

         Add paragraph preceding the one starting on line 37:

           "If any operand is a signalling NaN, Invalid operation

Technical  10.4
P57 L37  With the changes in 3.1 regarding arithmetic and basic formats,
         this paragraph does not make sense anymore.

         Drop the last part, starting with "unless that format...".



Michel.

P.S.  Some of my points were also addressed by David Hough.  I'll have
      to print out the auxiliary .pdf files mentioned in his ballot5.html
      before I can comment more on this.
Sent: 2008-01-28 02:31:51 UTC