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