Comments on clause 9. Recommended operations in draft 1.6.0, jan 10, 2008
Clause 9 on Recommended operations, i.e. correctly rounded
mathematical functions, is the result of subsequent changes that have
never addressed the real problems. In my opinion, all these changes
have been improving the draft on some points without being concerned
with over-all consistency of the clause. Proposals as published on
http://perso.ens-lyon.fr/christoph.lauter/revisionIEEE754.txt and
indicated to the board have not been taken into account. I consider
them to be the right way however, because they have never been openly
criticized.
In my opinion, clause 9 is now mainly inconsistent in several points
of view. Firstly, on page 49, line 7, one reads "Language standards
and implementations might define floating-point functions, not
otherwise defined in this document, that conform to this standard by
meeting all the requirements of this subclause." In other words, the
standard explicitly envisages functions, such as e.g. secpi(x) =
sec(pi * x), that do not figure in Table 9.1. The standard
nevertheless fails to give correct and consistent rules for special
cases. In the example, secpi(1.5) and secpi(-1.5) would evaluate to
+inf resp. -inf as per the rule on page 49, lines 34 to 36, "in order
to preserve sign symmetry even trough evaluation of poles". The
function secpi(x) = sec(x * pi) is even. This problem could perhaps be
patched by adding a case. The next point is harder to patch.
The standard explicitly considers bivariate functions as recommended
operations in table 9.1, such as e.g. pow, hypot or
atanPi. Nevertheless, general rules as the rule for divideByZero given
on page 49, lines 31 thru 36, or the subclause "9.1.2 Special operand
zero" apply only for univariate functions. In fact, all special cases
for these bivariate functions are explicitly given under subclause
9.2.1. One could thus think that no attempt is made in the standard
for specifying the behavior of bivariate functions in the general
case. However, this assumption also turns out to be false.
The clause "invalid operation" on page 49, lines 19 thru 30, is
applicable for bivariate functions and explicitly motivated by the pow
function (lines 29 and 30). Nevertheless it is intended only for this
particular case and constructed in such a way that pow(0,0) = 1. It
even contradicts the special values atan2pi(+-0,-0) = +-1,
atan2Pi(+-0, +0) = +-0 given on page 53, lines 12 and 13. If the rule
applied, the value nu should be the same for all combinations of signs
for zero operands. Remark that 9.1.2 does not apply for this
bivariate function. Actually, the limit lim mu(S) -> 0 mu_notnu(S) /
mu_nu is actually not 0 but alpha/(pi - alpha) where alpha is half the
least subnormal of the considered format. By the rule, atan2pi should
thus be NaN.
Similar problems are observed for non-analytic functions (page 49,
line 22) or functions that cannot be developed in 0 (page 50, lines 6
and 10). There are additional small errors at page 49, line 26, 27 and
28 (mu_...(S) instead of mu_...(x)), page 49, line 22 (binding x by
"and let x in R^n be a point in the real domain of f" makes no sense)
and page 50, lines 6 and 7 (at which point should the "Taylor series
expansion" be developed?). Further, the entry for rSqrt in Table 9.1
which indicates "default result +-inf" is inconsistent with the rule
at page 50, line 15, demanding that both f(-0) and f(+0) shall be
whichever of lim x->0- f(x) or lim x->0+ f(x). The first limit does
not exist.
In my eyes, there is no easy way of patching these "general" rules
given in subclauses 9.1.1 and 9.1.2. If it is too late in the
standardization process for important changes on sound mathematical
grounds as proposed in the past (see above), these rules should be
removed from the draft and the special cases of the functions figuring
in Table 9.1 should be added. The standard should then state clearly
that only functions in Table 9.1 are to be considered conforming. This
is clearly not the solution I was intending but prevents further
generations of people involved in revisions of the standard from
having to deal with "legacy" implementations based in this (at the
moment inconsistent) revision.
Besides these important points, there are small typos in subclause
9.2.1 page 52, lines 16, 17, 20, 21 and 22. By definition (page 52,
line 6), n is integral. There is no point in specifying that n is
integral.
Christoph Quirin Lauter
Arenaire team
Ecole Normale Superieure de Lyon
46, allee d'Italie
F - 69364 Lyon
christoph.lauter@ens-lyon.fr