P754 rogue comment on preferred exponent

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

Recently I studied draft 1.5.0 with respect to the treatment of
preferred exponent for decimal operations, and found three problems.

(1)  roundToIntegralExact(x)

     Clause 5.3.1 states that the preferred exponent is max(Q(x),0),
     but says nothing about exact vs. inexact (unlike some other
     operations).  The general rule in Clause 5.2 suggests that
     "Inexact" implies selecting the smallest possible exponent, but
     one can also read roundToIntegralExact() as always delivering
     an exact result, even though the Inexact condition may arise.

     I think that can be made crystal clear with two small changes:

     Page 26 line 25, 4th paragraph of clause 5.2, mention a second
     exception to the general rule:

        "For all computational operations except quantize and
        roundToIntegralExact, if the result is inexact ..."

     Page 27 line 7, description of roundToIntegralExact:

        "The preferred exponent is max(Q(source), 0), even when
        Inexact is signalled."

        (By the way, the current text uses Q(x), even though the
         operation is described as roundToIntegralExact(source).
         This same mistake occurs on line 4 of the same page.)

    (It is possible that the clarification belongs on page 36
     line 23, in Clause 5.9 where details are given.)


(2)  nextAfter(x,y)

     Page 27 line 26 (in Clause 5.3.1) is incorrect; it should say:
        "The preferred exponent is Q(x) when x=y,
        and the least possible otherwise."

     (I hear, from MFC, that this point may be moot now.)


(3)  Clause 9.2, Recommended correctly-rounded functions.

     No preferred exponent is mentioned at all, even though several
     functions can have exact results.  We are very fussy about the
     sign of zero, but apparently don't care about its exponent (for
     decimal formats).

     I don't have a specific recommendation, as there are several
     sensible possibilities, including the one of leaving the choice
     open -- but something has to be said!  Here are some alternatives:

     (a) Implementations are free to choose the cohort member of
         decimal results.  In practice this will almost always be
         the one with the least possible exponent, as almost all
         results are inexact -- but for exact results there is no
         specific requirement.

     (b) The preferred exponent is always the smallest possible,
         whether the result is exact or not.  This mimics the binary
         case, where full precision is used (except for subnormals).

     (c) The preferred exponent is always the smallest possible,
         except for exact -1, 0 and +1, where it is zero.

     (d) The preferred exponent is zero for exact results, when the
         arguments are in the domain for which correctly-rounded
         results are claimed.  This should always include exact
         results of -1, +-0, and +1.

     (e) Each function capable of producing exact results (this
         includes exp2, exp10, log2, log10, hypot, sinpi and friends,
         and possibly pown and rootn; perhaps even pow and compound)
         should document a formula for the preferred exponent of
         claimed exact results.

Sincerely,
  Michel Hack.
Sent: 2007-12-20 04:20:14 UTC