SC22/WG11 N442

Disposition of Comments received on FCD Ballot for:

ISO/IEC CD 10967-2 LANGUAGE INDEPENDENT ARITHMETIC

Part 2: Elementary Numerical Functions

The FCD was SC22 document N2397, the Summary of Comments was SC22 document N2505

UK COMMENTS ON N2397 FINAL CD BALLOT: ISO/IEC CD 10967-2 LANGUAGE INDEPENDENT ARITHMETIC Elementary Functions

The UK votes YES to accept this document as a Final CD.

In addition to the comments below on the document the UK would also like to stress the following points:

1. We understand that, in some programming communities, integer values stored in a floating point datatype are treated differently from other floating point values.

However, we strongly support a clear separation of values which are always exact, i.e. the integer datatype, from values which are always approximate, i.e. the floating point datatype, within this Standard. In our view it is not possible for an approximate value to be deemed to be exact.

This does not preclude a specific programming language from allowing such a conversion.

ACCEPTED (no change needed for this)

WG11 supports the view that integer and floating point values should be treated separately. However, it is not the case the floating-point values are always approximate. They are sometimes exact. From the point of view of specification, floating-point argument values are treated as exact, since they may be so. Results are either approximate or exact, under the assumption that the arguments are exact. If the arguments are approximate, there will be an accumulation of the errors, but that is out of scope for LIA-2 itself.

2. Regarding the distinguishing of infinities it is our view that it is important to distinguish between user-created ones, e.g. poles created by divide by zero, and others, such as accumulated values becoming too large, if at all possible. We would like to see LIA-1 amended to allow for this at its next revision.

REJECTED

WG11 does not oppose this suggestion based on it merits. But WG11 is not powerful enough to influence hardware and system software vendors to change the basic representation of floating point values. The specifications given in LIA-2 need to be based on already existing floating point datatypes, the IEC 559 floating-point data types in particular. These do not in the values themselves distinguish between exact and approximate infinities. However, when an approximate infinity is generated, an overflow notification shall be generated. Current technology is however to keep the overflow notification separate from the continuation value. LIA-1 requires that each thread keeps its own indicators for recording arithmetic notifications. That is about as far as WG11 can go without risking the entire standard to be ignored. (Note that some planned architectures that rearrange instructions at runtime will have "processor minithreads", each keeping their own IEEE floating point exception indicators.)

So, if we were to introduce a distinction between approximate and exact infinities, it is very unlikely to be adopted, and may hinder the success of LIA-2.

3. Clause 5.5 page 10

We are not happy about an implementation being REQUIRED to provide a lower level of accuracy at a higher performance. We believe that

a) this should only be optional and

b) that the user should be provided with sufficient information in such a case as to be able to make an informed decision as to whether the speed gain is worth the loss of accuracy.

ACCEPTED

The formulation in the CD2 at this point is erroneous. It was never the intention to make that a requirement. The text will be changed.

- --------------------------------------------------------------------------

The following comments on the document relate to minor technical or other issues.

Note: Maths text is \TeX\ formatted.

1. Clause 5.6

Replace heading "Extensions" by "IEC 559 Special values". Does this change need to be made anywhere else?

ACCEPTED

The text will be changed and checked.

2. General

The disposition of comments (N2391, p11, clause 3 The major issues, point 4) said that the IEC special values would be in bold type. But '-0' and the others are not clearly in bold. It is essential that these values are not confused with normal mathematics.

This should be checked with the special values possibly specified differently, i.e. in a different font to the Bold one currently being used.

ACCEPTED

This seems to be due to some TeX-technical problems. The 0 in -0 is now in bold. The -, + and infinity symbols are not, since bold symbol TeX fonts are missing in the editor's TeX installation. However, the most important distinction, that between negating mathematical 0 and the IEC 559 negative 0 is made visible now.

3. Clause 9.3 Page 16

Why is there a difference in the second case of the exceptions on page 16 from the corresponding integral power functions on page 17? Shouldn't it be

$$\hbox{\it POWER}_{FF}(0,0)=\hbox{\bf bad{\_}argument}$$

rather than

$$\hbox{\it POWER}_{FF}(0,0)=\hbox{\bf pole}(\infty)?$$

I.e. for the first TWO exceptions, the respective if-clauses should be

1. if $x<0$ or $x=y=0$;

2. if $y<0$.

If on the other hand the original formulation is the intended one, then there should be additional rationale explaining the difference.

ACCEPTED

The specifications for power operations will be thoroughly revised. They are currently incomplete and erroneous. This and other errors will be corrected. See the new (editor's; that may become WG11's) draft specifications.

4. Clause 10.3 Page 19

There is a typographic error on the first line (filename "plia2.tex" should not be there!)

ACCEPTED

Will be removed.

5. Clause 10.3 Page 19

Line 2 of the axioms appears to be in contradiction with line 2 of the special values clause, unless a clause is added to the latter to make it read

$$\hbox{\it LOG}_{FF}(1,w)=\hbox{\bf bad{\_}argument}

\quad\hbox{if $w=0$ or $w=\pm\infty$}$$

The if-clause in line 1 could be simplified to

if $w\le 1$.

ACCEPTED

The specifications for log operations will be thoroughly revised. They are currently incomplete and erroneous. See the new (editor's; that may become WG11's) draft specifications.

6. Clause 11.14 Page 26

Line 2 of definition, "pi" should be Greek symbol.

ACCEPTED

Will be fixed.

7. Clause 11.14 Page 27

Last two cases of exceptions, letters 'x' and 'u' should be italic.

ACCEPTED

Will be fixed.

8. Clause 11.17 Page 28

Typo on 4th exception -- too much white space!

ACCEPTED

Will be fixed.

9. Clause 17.8 Page 51

Insert line break between "w" and "MIN2 F"

ACCEPTED

Will be fixed.

10. Clause 20.1 Page 57

It seems that the if-clause in the second line of exceptions simplifies to if $x^2+y^2<fmin_N^2$ unless it matters precisely which of the quantities ($\max{x^2,y^2}$, $\min{x^2,y^2}$ or $x^2+y^2$) are considered. In that case a (clearer) comment to this effect is in order. (SEE NEXT ITEM.)

ACCEPTED

Will be simplified, and use 'trans_result_F' (similar to 'result_F') helper function instead.

11. Clause 20.1 Page 57

First line of exceptions seems to contradict rationale in A.20.1, (line 2, page 79), which states that HYPOT must never produce an underflow. (SEE PREV. ITEM.)

ACCEPTED

Hypot_F can underflow. The text in the rationale will be corrected.

12. Clause 10.3 Page 19

This is more in the nature of a philosophical question than a comment about the draft. Why would it be a bad idea to implement logarithms with fractional bases via

$$\hbox{\it LOG}(1/b,x)=-\hbox{\it LOG}(b,x) \quad\hbox{if $b\in (1,\infty)$}(??)$$

and thereby extend {\it LOG} to bases $b\in (0,1)$?

ACCEPTED but with other details

The particular specification that is suggested is technically flawed, 1/b is unlikely to be in F even when b is in F. However, we agree that the logarithm operation taking a base argument should allow also for a base strictly between 0 and 1. A proper specification for allowing this will be used. See the new (editor's; that may become WG11's) draft specifications.

- -------------------end of UK comments ---------------------------

------------------------------------------------------------------------

Comments from Germany accompanying their negative vote

DIN - NI - 22.11

c/o Prof. Dr. Wolfgang V. Walter

Technische Universitaet Dresden

Institut f. Wissenschaftliches Rechnen

Fachrichtung Mathematik

Mommsenstr. 13

D - 01062 Dresden

Germany

Tel: +49 - 351 / 463-3996 or -4266 (secr.)

FAX: +49 - 351 / 463-7114

e-mail: wwalter@math.tu-dresden.de

=======================================================================

Germany believes that CD 10967-2, also known as LIA-2, is NOT ready

for registration as a final CD and should not be approved.

=======================================================================

We agree with most of Fred Tydeman's comments which he sent DIN (and also X3J11) on March 10, 1997, except for 31) and 33). Mr. Tydeman lists 101 minor and major technical problems and typos which are indicative of the failings of the current draft.

In essence, we believe that the current draft of LIA-2 should be extended, corrected, or made more explicit in the following areas:

1. Accuracy: (see also Tydeman's comments 9, 10, 12)

The definition of OP in section 5.2 together with implementation-dependent values for max_err_OP leave a mulitude of loopholes for an implementation, making standard-conformity an extremely non-portable and thus user-unfriendly thing. The relationship with roundings is unclear (see below).

REJECTED (see below)

More rigorous minimal accuracy requirements would be much more helpful, for the user and for the implementor. For example, it seems virtually impossible to implement a rigorous interval function library on top of the functions as currently provided by LIA-2.

REJECTED (the accuracy requirements are already rigorous; see below)

By the way, there are excellent examples of absolutely reliable transcendental functions with rigorous error bounds available, e.g. from SUN or from the University of Karlsruhe (for PASCAL-XSC or C-XSC from Kulisch, Kraemer, Hofschuster).

(Response to the three paragraphs above) The max_err_OP parameters are intended to make accuracy information available to programs. (We will strongly decrease the number of such parameters. The current approach of having one such parameter per operation is too unwieldy.) There are rather tight requirements on the maximum values for the max_err_OP parameters. For (full!) conformity the max_err_OPs must usually be less than 1 or 2 (ulps). Consider that a "perfect accuracy" implementation would have all max_err_OPs to 0.5 (ulps), and that Ada currently specifies wider error bounds than LIA-2 does. The current requirements on max_err_OPs are thus already fairly tight.

In order to allow for a rigorous interval function library to be implemented on top of LIA-2 conforming operations, it is not really sufficient to have rigorous error bounds (which LIA-2 already has). To get the intervals really tight one needs to be able to guarantee that the result is either always greater than (or equal to) the true result, or always smaller than (or equal to) the true result. However, a slightly less rigorous interval function library can be implemented on top of numerical functions (fully!) conforming to LIA-2. This is currently deemed sufficient.

We are not sure what is meant by "absolutely reliable". Does it mean that the maximum error is 0.5 ulp?

The allowance (requirement?) that a slow and accurate and a fast and sloppy version should be provided opens a can of worms. This cannot be left in as part of an international standard unless a substantial clarification of this issue is attempted.

PARTIALLY REJECTED (the "sloppy" version cannot, even now, fully conform to LIA-2, it will continue to be allowed as partially conforming).

PARTIALLY ACCEPTED (the "requirement" will be removed, and the text will be made clearer).

The current "requirement" will be made into option for having also implementations (alternative libraries) that are in "partial conformity" with LIA-2. It may be useful to allow for efficient implementations that cannot conform to the maximum error bound requirements, but conforms in other ways (notifications, results for infinity arguments, etc.). Such partially conforming implementations may not be suitable to build an interval library upon. We will attempt to clarify the intent.

2. Rounding: (see also Tydeman's comment 11 and others)

It is unclear whether rigorous error bounds can be obtained for each function by using upwardly and downwardly directed roundings. The interaction between the current rounding mode and the evaluation of a function is often unspecified. If taken into account, the rounding mode would lead to more detail (cases). If it is intended to give support for interval functions, this has to be made much more explicit and precise. Currently, this is not continuing in the tradition of LIA-1.

REJECTED (rounding mode may or may not predictably affect the result)

See also the response immediately above. It not the intent that changing the (IEEE) rounding mode is to have a predictable effect on the result of the elementary transcendental numerical functions, other than it may have no effect. We will add a documentation requirement that the behaviour of a particular implementation is to be stated.

Note that LIA-1 does not, itself, require any rounding modes, or predictable change when a rounding mode is changed, unless the parameter iec_559_F is true, in which case LIA-1 (by reference to IEC 559) requires that the specifications in IEC 559 is followed. This may require certain compilation instructions to be employed.

3. Higher Precision:

While it is commendable that "Doubled precision operations" are specified in chapter 18, their utility has only been proven in very restricted situations/applications. At times, it is certainly useful to be able to compute the low-order part or the remainder of an operation. In general, however, the most generally applicable operation is "accurate accumulation". If arbitrary sums of numbers and products can be computed with known or user-specified high accuracy (even in the presence of leading-digit cancellation), then all elementary operations on multiprecision numbers, vectors, and matrices become virtually trivial to implement.

We believe that LIA-2 should include some useful and efficient facilities for implementing vector and matrix (dot) products and elementary multiprecision arithmetic. This is extremely cumbersome when one has to resort to the low-order parts of addition and multiplication. Precise specifications for such facilities exist and can be supplied by DIN (Wolfgang Walter).

PARTIALLY REJECTED (if DIN does not supply draft specifications very soon)

A request to Wolfgang Walter to supply these specifications was made late in 1997, to the e-mail address specified above. No specifications have been received by the editor to date (aug. 1998).

PARTIALLY ACCEPTED (provided DIN does supply draft specifications)

The comment does not provide specifications, and DIN has not supplied specifications, though asked. The operations asked for could be provided in another part of LIA, or in a later version of LIA-2.

The low-level extended precision operations are provided to *support* the implementation of higher-precision libraries, not to actually specifiy the operations in them.

We agree that the current "sum" operations should be replaced by a better specification. WG11 would appreciate being sent the specifications you mention for consideration.

In the meantime, a specification for exact summation of a sequence of floating point values is included. Review of this specification would be appreciated.

- --------------------end of first set of comments -----------------

Comments by Mr Tydeman (who has been in Germany for 19 months), submitted to DIN NI-22 and to ANSI X3J11:

- -----

We have reviewed ISO/IEC 10967-2.2:1996(E), Second edition, December, 1996. Information technology -- Language independent arithmetic -- Part 2: Elementary numerical functions. That document will be called LIA-2 in the rest of this note.

The above document is the second committee draft submitted to SC22 to become a Final Committee Draft (FCD). The closing date for the ballot is June 19, 1997 (document SC22 N2397).

We have also reviewed four other documents that are related:

1) ISO/IEC 10967-1:1994(E) Information technology -- Language independent arithmetic -- Part 1: Integer and floating point arithmetic. That document will be called LIA-1 in the rest of this note.

2) CEI/IEC 559: 1989 Second edition, 1989-01, Binary floating-point arithmetic for microprocessor systems (also ANSI/IEEE Std 754-1985 IEEE Standard for Binary Floating-Point Arithmetic). That document will be called IEEE-754 in the rest of this note.

3) ISO/IEC 10967-2:1995(E), First edition, November, 1995. Information technology -- Language independent arithmetic -- Part 2: Elementary numerical functions.

4) SC22/WG11 N434 Disposition of Comments on first edition LIA-2.

================================================================

In summary, we believe that the LIA-2 document should NOT be approved.

There are still too many errors in it.

================================================================

The following numbered comments are in page number order.

The comments have been classified into four categories:

[major] Cause for "No" vote unless resolved in satisfactory way.

The comments marked as major have in this DoC been emphasised with bold (in the HTML version).

[minor] Not cause for "No" vote, but should be addressed.

[typo] Typographical or obvious very minor error.

[info] For your information.

1) [minor] Page ix. Please add a sentence saying if notes are normative or for information only.

ACCEPTED

Notes are for information only. A statement to that effect will be added.

2) [minor] Page x, last paragraph, last sentence. How does a program select the library best suited to its application? What parameters are used to make this selection? Our impression is there is one math library that conforms to LIA-2.

PARTIALLY ACCEPTED

There may be several libraries. Some may conform (fully) to LIA-2, some may conform partially (in a particular way, to be described in the LIA-2 text) to LIA-2. Even some that do not conform. The sentence should say that a **programmer** can select a suitable library, based on the required documentation of the partially or fully conforming libraries. Parameters are made available (via the partially or fully conforming libraries) to the programs in order to enable them to *detect* the *declared* accuracy of the library used, or use these values in automatic error analysis. These parameters are not primarily present to enable *programs* to select a library, but rather enable the programmer to do the selection. The formulation in the Introduction will be changed to reflect this.

3) [minor] Page 1, section 1.1, 2nd paragraph, change "exceptional input value" to "IEC 559 special value" or "IEC 559 continuation value".

ACCEPTED

"the results produced when one or more operand value is an IEC 559 special value."

4) [minor] Page 2, section 2.1 and following. Change "operations" to "numerical functions". This document is about numerical functions, not arithmetic operations.

REJECTED

In the LIA-2 document the term "numerical function" means "a computer routine or other mechanism for the approximate evaluation of a mathematical function"; and "operation" means "a function directly available to the user/programmer, as opposed to helper functions or theoretical mathematical functions". "Numerical function" thus cover "operations", but may refer to "computer routines" that are not directly available to user/programmer. Whether "operator" or other syntax is used in a binding (or in conventional mathematical notation) is another matter, and out of scope for LIA-2 itself (though some operators are used in the example bindings syntax).

5) [minor] Page 2, section 2.2, 1st paragraph, what does ", and no others" mean? Is an input or output operation (which most languages have) considered part of "others"?

ACCEPTED

Section 2.2 is removed entirely. Adding a note to section 2: "It is not possible to conform to LIA-2 without specifying to which set of operations conformity is claimed."

6) [minor] Page 7, item 22. Change "digits in the fraction" to "radix-r digits in the fraction f in 0.f*r**e". We are used to scientific notation where there is one digit before the decimal point and several fraction digits after the decimal point.

PARTIALLY ACCEPTED

A "(See 5.2 of LIA-1.)" will be added.

7) [minor] Page 8, item 34. Change "normalized value x" to "normalized value x (0.f*r**p)".

PARTIALLY ACCEPTED

"normalized value x" will be changed to "value x".

8) [minor] Page 8, section 5, 3rd paragraph. Change "error limit, and extensions" to "error limit, and IEC 559 special values".

ACCEPTED

9) [major] Page 9, section 5.2 Definition. The definitions given in sections 8 and higher are not consistent. Some exclude all domains where exceptions happen, others exclude some of the domain where exceptions happen. Contrast 11.1 sin() and 11.7 tan(). You may need to add a paragraph to this section explaining the intent.

ACCEPTED

Each specification will be corrected and made complete. The specifications will apply to all of F, and to all IEC 559 special values.

10) [major] Page 9, section 5.2, item b). Change the "OP" in the exponent to lower case so that the error is calculated in terms of the correct mathematical result, instead of the computed result. The program can still estimate the error based upon the calculated value, but the error limits for conformance must be defined in terms of the true mathematical value. It matters the most when the true value is just below a power of the radix and the calculated value is just above that same power of the radix. Using the calculated value to compute the error bound results in an error "radix" times as large as using the true value.

ACCEPTED

There will be a correction along these lines. LIA-1:1994 has the parameter rnd_style, which can be used to say that the rounding style is to nearest, when the error bound is 0.5 ulp. (LIA-1 should be similarly corrected, which means that the rnd_style parameter could be removed.)

11) [major] Page 10, section 5.3. It is not clear if axioms and the functions are dependent upon rounding or independent of the rounding. For example, if the user changes the rounding to plus infinity, calls a function, then changes the rounding to minus infinity and calls the same function with the same argument (so as to get the bounds of the result), must the function honor the rounding? May the function honor the rounding? Or, must the function be independent of the rounding? If rounding matters, than many of the axioms in sections 8 and higher are false, in particular, those that state that f(x) is x if x is small.

PARTIALLY ACCEPTED

The intent is that the implementations of the numerical functions may be such that they ignore the rounding mode, or may produce another value, but not necessarily according to the rounding mode. A documentation requirement regarding this will be added.

12) [major] Page 10, section 5.5, 2nd paragraph. What is the meaning of "each such operation provided by an implementation must also be provided at lower accuracy and higher performance."? This is new with the second edition. It also is a contradiction to the Introduction on page x where it is a recommendation. In reading the response to the Japan's comments to the first edition "It is intended that an implementation provide a library of reasonably high accuracy, and also provide one of lower accuracy, with error bounds three or four times greater than those for high accuracy.", it appears that there is supposed to be an accurate and slow library and a sloppy and fast library. That intent needs to be made clearer. For example, is the lower accuracy library still required to meet the accuracy requirement of LIA-2? How does the program select the accurate or sloppy version? Is it done at compile time, link time or at runtime?

ACCEPTED

The "requirement" will be lifted out. The intent is that a less accurate library *may* be provided. This library is not intended to be fully conforming to LIA-2, but it may be partially conforming (conform to all the other requirements, except the accuracy requirements). The selection would be done by the programmer, not the program.

*13) [minor] Page 11, section 5.6 title. Change "Extensions" to "IEC 559* *Special Values".*

ACCEPTED

14) [major] Page 11, section 6, 4th paragraph. First choice is to remove the entire paragraph, second choice is to change it so that functions may optionally signal underflow for denormal arguments. It appears that you tried to apply the idea that f(x) is x (not underflow) for denormal x to the rest of the document, but you did not do a consistent job. For example, you say sin(x) for a denormal is not underflow, yet sinh(x) and arcsin(x) for a denormal are underflow.

PARTIALLY ACCEPTED

The specifications will be made consistent. This paragraph will still be made into a note, since the exact specification is done for each operation. Note, however, that the intent is to avoid underflow notifications when there is a denormal argument only if there *never* is any denormalization loss for the operation, regardless of argument(s).

15) [minor] Page 11, section 6, 6th paragraph. Change "signaling NaN as an input, then a bad_argument notification shall result" to "signaling NaN as an input, then a bad_argument notification shall result with a quiet NaN as the continuation value".

ACCEPTED

But we will move this to the specification for each operation.

16) [minor] Page 11, section 6, 6th paragraph. Add "Functions with one quiet NaN input return that same quiet NaN. Functions with multiple quiet NaN inputs return one of the input quiet NaNs."

REJECTED

1) NaNs are unidentifiable in the eyes of LIA-2.

2) We do not want to prevent better ways of merging NaNs.

Thus a requirement that any particular NaN is to be returned will not be added to LIA.

17) [minor] Page 15, section 9.2, in the Note. Remove the word "only".

ACCEPTED

18) [major] Page 16, section 9.3, Exceptions. Rewrite the case of x < 0 into cases that cover integers and non-integers. POWER( -2.0, 2.0 ) and POWER( -3.0, 3.0 ) are well defined. We disagree with your assumption in A.9.3 that integer floating-point values are approximate.

REJECTED

While floating point values may be exact, and LIA-2, in order to maintain high accuracy requirements, usually regard floating point values as exact, we also realise that floating point values may be approximate, and usually are. The current design in regard to the power operations is based on that observation, and on that for Ada one has made the same design decision.

19) [minor] Page 17, section 9.6, title. Change "known base" to "integer base".

REJECTED

No, only two "known" fixed bases are treated in this section, base 2 and base 10.

20) [minor] Page 17, section 9.6.1 and 9.6.2, Axioms. The domains are not consistent. One mentions fmax, the other fmin. It seems that the domains should be the same domain as in the Definition section.

PARTIALLY ACCEPTED

The specifications will be corrected, but not in the way suggested. The entire specification style is changed, and no "definition section" with domain appears.

21) [minor] Page 17, section 9.6.1, section Exceptions. Change "x <=" to "x <". On a binary machine, log2(fminN) is an exact integer, so underflow will not happen for exp2(log2(fminN)).

PARTIALLY ACCEPTED

The specifications will be corrected, but not in the way suggested. Note that the specification is regarding exp2_F(log_2(x)), not 2^(log_2(x)), and in addition LIA-2 does not require the radix to be 2.

22) [minor] Page 18, section 9.6.2, section Exceptions. Change "x <=" to "x <". On a decimal machine, log10(fminN) is an exact integer, so underflow will not happen for exp10(log10(fminN)).

PARTIALLY ACCEPTED

The specifications will be corrected, but not in the way suggested. See the reply to comment 21 above.

23) [major] Page 18, section 10.1, IEC 559 Special Values. Remove the bad_argument exception for ln(+INF). Make it consistent with sqrt().

ACCEPTED

This correction will be made. It follows the principle that arguments are to be treated as exact.

24) [major] Page 19, section 10.2, IEC 559 Special Values. Remove the bad_argument exception for ln1p(+INF). Make it consistent with sqrt().

ACCEPTED

This correction will be made. It follows the principle that arguments are to be treated as exact.

25) [minor] Page 19, section 10.2, in the Note. Remove the word "only".

ACCEPTED

26) [typo] Page 19, section 10.3, before Signature. What is "plia2.tex"?

ACCEPTED

That text will be removed.

27) [type] Page 19, section 10.3, IEC 559 Special Values. What is the ">/" symbol in "if w >/ 1"? Should it be w not element of F or w <= 1?

ACCEPTED

>/ will not be used.

28) [minor] Page 19, section 10.3, IEC 559 Special Values. Remove, or explain better, the log(1,w) = bad_argument case. log of 1 for any valid base is 0.

ACCEPTED

The specifications will be corrected.

29) [major] Page 19, section 10.3, IEC 559 Special Values. Remove the bad_argument from log(+inf,w) = bad_argument (+inf) case. Make it consistent with sqrt().

ACCEPTED

This correction will be made. It follows the principle that arguments are to be treated as exact.

30) [minor] Page 19, section 10.4, title. Change "known base" to "integer base".

REJECTED

No, see response to your comment 19.

31) [minor] Page 19, section 10.4.1, many sections. Replace lower case "log_2" with "log2" where the 2 is a subscript.

ACCEPTED

32) [major] Page 20, section 10.4.1, IEC 559 Special Values. Remove the bad_argument exception for log_2(+INF). Make it consistent with sqrt().

ACCEPTED

This correction will be made. It follows the principle that arguments are to be treated as exact.

33) [minor] Page 20, section 10.4.2, many sections. Replace lower case "log_10" with "log10" where the 10 is a subscript.

ACCEPTED

34) [major] Page 20, section 10.4.2, IEC 559 Special Values. Remove the bad_argument exception for log_10(+INF). Make it consistent with sqrt().

ACCEPTED

This correction will be made. It follows the principle that arguments are to be treated as exact.

35) [minor] Pages 21 to 28, sections 11.1 to 11.18, Exceptions. Many of the definitions of underflow are in terms of fmin which should be fminN.

ACCEPTED

36) [minor] Page 21, section 11.1, Exceptions. For the underflow case, change the "1 <= |x|" to "0 <= |x|".

REJECTED

The intent is that for denormal *x* there is no underflow for this operation, when the argument is denormal. There may, under rare circomstances, be an underflow for an argument that is not denormal.

37) [minor] Page 21, section 11.2, Axioms. Add SIN(u/2,u) = 0.0

ACCEPTED

38) [minor] Page 21, section 11.2, Exceptions. For the underflow case, change the "u/8 <= |x|" to "0 <= |x|".

ACCEPTED

39) [typo] Page 22, section 11.5, Axioms. The exponent "(-1-p/2)" needs to be fixed so that it is all an exponent.

ACCEPTED

40) [typo] Page 28, section 11.17, Exceptions. "if ( 2|u," is missing some text.

ACCEPTED

Will be fixed. The divides predicate (|) is only defined for integers, so its use here was illformed. The new specifications will not use the divides predicate on non-integers.

41) [typo] Page 29, section 12.1, Signature. Change "bad_argument underflow" to "bad_argument, underflow",

ACCEPTED

42) [minor] Page 29, section 12.1, Axioms. Change "|x| <= fmax" to "|x| <= 1".

ACCEPTED

43) [minor] Page 30, section IEC 559 Special Values. Here and in many following functions, there is a function N() that is not defined (that we can find). We assume it is nearest rounding.

ACCEPTED

The name will be changed to nearest_F. CD2 has a definition on page 29.

44) [major] Page 32, section 12.8, IEC 559 Special Values. Remove the bad_argument exception for arctan(+INF,w) and replace it with pi/2. Make it consistent with sqrt().

ACCEPTED

45) [major] Page 32, section 12.8, IEC 559 Special Values. Remove the bad_argument exception for arctan(-INF,w) and replace it with -pi/2. Make it consistent with sqrt().

ACCEPTED

46) [major] Page 34, section 12.14, IEC 559 Special Values. Remove the bad_argument exception for arccot(+INF,w) and replace it with +0. Make it consistent with sqrt().

ACCEPTED

47) [major] Page 34, section 12.14, IEC 559 Special Values. Remove the bad_argument exception for arccot(-INF,w) and replace it with -0. Make it consistent with sqrt().

ACCEPTED

48) [typo] Page 42, section 15.1, title. Change "Convert to float" to "Convert to integer".

ACCEPTED

49) [minor] Page 43, section 15.3, Definition. Change "<= x <=" to "< x <". Since you allow round to nearest to round up or down, maxint + 1/2 could round to maxint + 1 which is overflow.

PARTIALLY ACCEPTED

We will revise this specification. It will use a 'nearest' (renamed to 'round') that rounds ties to the even integer.

50) [minor] Page 45, section 15.9, Exceptions. Change it so that floor(0.0) is 0.0, not underflow. For example, if 0 < |x| < fminNG.

ACCEPTED

51) [minor] Page 45, section 15.10, Exceptions. Change it so that ceiling(0.0) is 0.0, not underflow.

ACCEPTED

52) [minor] Page 45, section 15.10, IEC 559 Special Values. Why are -0, infinity, and NaN allowed to be in one floating type (F), but not another floating type (G)? Why is that case allowed for here, but not in DPROD (section 19.1)?

REJECTED

Dprod is intended to be *within* one "family" of floating point types (text will be added to Annex A on this). The conversion functions may convert *between* "families" of floating point types. E.g. floating point values for some other (presumably old) machine that are imported in their old binary representations, and then converted to the executing (presumably newer) machine's representation.

53) [typo] Page 45, section 15.10 and higher, make the "if"s line up vertically.

ACCEPTED

54) [minor] Page 45, section 15.11, Exceptions. Change it so that nearest(0.0) is 0.0, not underflow.

ACCEPTED

55) [minor] Page 46, section 15.12, Exceptions. Change it so that truncate(0.0) is 0.0, not underflow.

ACCEPTED

Truncate is already in LIA-1, and need not be repeated in LIA-2.

56) [minor] Page 48, sections 16.2.1 to 16.2.4, IEC Special Values. Add "f(SNaN) causes no notification". Need some way to print SNaNs.

ACCEPTED

All of the conversions should convert SNaNs quietly.

57) [minor] Page 49, section 16.3, 2nd paragraph. Since compile time literal conversion and runtime input conversion need not be identical, there should be an error bound on the difference between them.

REJECTED (they are required to be identical)

The compile time literal conversion and runtime input conversion shall be identical in result, given literals for the same value in R, except that notifications occurring at compile time can be reported as errors at compile time rather than being deferred until runtime, and that the syntaxes for internal and external numerals may differ (but syntax is out of scope for LIA-2). The error bound on the difference you refer to shall thus be 0, for LIA-2 conformity.

58) [typo] Page 51, sections 17.6 and 17.8, IEC Special Values. Add some spaces before F(w,v) = F(v,w) and after the +INF.

ACCEPTED

59) [minor] Page 51, section 18, first paragraph. Change "2p-3" to "2p" or explain why the -3.

REFORMULATED

This is a moot point. "Doubled precision" does *not* give (a pair) result that is valid to "2p" digits, nor "2p-3" digits. The result is a pair, which in come cases (e.g. f.p. addition when add_F uses round to nearest) is exact, in some other cases it is inexact. When exact, the operations can be used to implement very accurate, or even exact, summation, vector product etc. When inexact, the result is still more accurate than without "doubled precision", and the additional accuracy may be used to return a more accurate, though then not exact, final result. However, since the result is a pair of floating point values, that may have widely different exponents, one cannot characterise the precision by mentioning a single number of digits for the accuracy of the pair combined.

60) [minor] Page 52, section 18.2.1, IEC 559 Special Values. Change the bad_argument cases to be 0.

PARTIALLY ACCEPTED (applies to 60, 61, 62, 64)

These cases are concerned with the "low" part of adding (IEC559) infinities with infinities or other values. When, e.g., +inf is added to 5, one could argue that the low part should be 0 (and changes to this effect will be made), but when +inf is added to -inf (which returns "invalid"), the low part should also be "invalid". However, there may be a small efficiency loss when returning 0 rather than invalid in the first case. Similarly for the other "low part" operations.

61) [minor] Page 53, section 18.2.2, IEC 559 Special Values. Change the bad_argument cases to be 0.

See above.

62) [minor] Page 53, section 18.2.3, IEC 559 Special Values. Change the bad_argument cases to be 0.

See above.

63) [minor] Page 53, section 18.2.4, Error limit. What is "xhi(x,y)"?

A typo. div_F was intended.

64) [minor] Page 54, section 18.2.5, IEC 559 Special Values. Change the bad_argument cases to be 0.

See above.

65) [minor] Page 56, section 19.2, IEC 559 Special Values. Change the bad_argument cases to be 0.

REJECTED

Just as mul_F(+inf,0) returns invalid, so does dprod for such arguments.

66) [minor] Page 57, section 20.1. The text description says that underflow does not occur, yet underflow shows up in the exceptions section.

ACCEPTED

Will be corrected, hypot_F can underflow.

67) [typo] Page 57, section 20.1, IEC 559 Special Values. Change "(w.v)" to "(w,v)".

ACCEPTED

68) [minor] Page 57, section 20.3, IEC 559 Special Values. Remove the DIM(NaN,w) case.

ACCEPTED

69) [minor] Page 58, new section. Please add an ulp(x) function that returns the value of an ulp of the argument x. ulp(small) can underflow if denormals are not representable. ulp(0.0) is bad_argument. ulp(infinity) is bad_argument. ulp(-x) == ulp(x).

REJECTED (already present)

This operation is specified in LIA-1. There is no need to redo it here.

70) [minor] Page 59, section A, Acknowledgements. Remove the X3 from X3T2. This may need to be elsewhere in the document.

ACCEPTED

Note that in the final standard we must remove the acknowledgements, indeed we will remove it now.

71) [minor] Add WG14/J11 to the list of standards committees that provided advice.

ACCEPTED

Note that in the final standard we must remove the acknowledgements, indeed we will remove it now.

72) [minor] Page 59, section A, Project milestones. Change "August

1996" to "December 1996".

ACCEPTED

Note that in the final standard we must remove the project milestones, indeed we will remove it now.

73) [typo] Page 60, section A.2, last line. Change "LIA=2" to "LIA-2".

ACCEPTED

74) [typo] Page 61, section A.5.2. Change "log" to "LOG".

PARTIALLY ACCEPTED

The entire paragraph is ill-conceived, and will be heavily reformulated.

75) [major] Page 62, section A.5.2. Change "OP(x,...)" to "op(x,...)" in the exponent of r for the error bound so that it computes the error in terms of the mathematical function and not the computer function.

ACCEPTED

76) [minor] Page 63, section A.5.5. Remove "It should be mentioned that an implementation can usually provide numerical operations with higher accuracy than that associated with the underlying basic arithmetic operations." How can "sin()" be more accurate than "+"?

ACCEPTED

The sentence will be deleted.

77) [minor] Page 63, section A.5.6, 2nd paragraph. The statement "LIA-2 requires conformance to IEC 559 by implementations which provide these special values" needs to be changed. Just because an implementation supports -0, +/- infinity, and NaN, does not mean that it is capable of conforming to IEC 559. There are systems that do not support denormal numbers, but do have those special values. There are systems that provide Signaling NaNs, but no Quiet NaNs, but do the rest.

ACCEPTED

The formulation will be changed.

78) [typo] Page 63, section A.5.6, 3rd paragraph. The reference to [37] is wrong because reference [37] appears to be two documents combined into one item.

ACCEPTED

79) [minor] Page 64, section A.5.6.4, 1st paragraph. Remove "(unjustified)".

ACCEPTED

80) [major] Page 65, section A.6. The idea that some underflows are better than other underflows, that is, some should be acknowledged but others ignored, should either be removed or made optional. Also, there is a factual error: Underflow can happen for a normal as well as a denormal input argument. Consider, sin(x), where x is the smallest normalized number. Since the series for sin() is x - x**3/3! ..., the mathematical result is a little less than the input, so in round to zero or round to minus infinity, the computed result is the largest denormal and hence underflow.

REJECTED

The idea is that underflow is supposed to indicate the possibility of a larger than 'normal' relative error (a possible denormalisation loss). If it is known that the relative error is within the 'normal' relative error (no denormalisation loss), then one should not, and most often shall not, indicate underflow. For example, for denormal/subnormal results IEC 559 specifies that if underflow is not trapped and the denormal result is exact, then no underflow notification is to be given. The cases in LIA-2 are supposed to be similar. If a denormal result is within the same relative error bound of the 'true' result as 0.5 ulp is for normal results, then there is to be no underflow notification.

81) [major] Page 65, section A.8.1, 2nd paragraph. The idea that some infinities are different from other infinities, that is, +inf from addition is different from +inf from multiplication is different from +inf from divide by zero, needs to be removed. It sounds like you want the math functions to check the exception flags and treat an input of +inf and overflow different from an input of +inf and divide-by-zero.

REJECTED (based on false assumptions)

There isn't really any such assumption, at least there is no way to tell the difference. This is mandated by IEC559. Even though the argumentation in the paragraph referred to is valid, there is also the principle that every value, even approximate ones, are treated as exact, for the purpose of giving high-quality specifications of the operations. For this reason, the paragraph referred to will be rephrased, and some specifications will be corrected to follow this principle as already set out.

82) [minor] Page 66, section A.9. Add a reference to a new entry in the bibliography to which X/Open Portability Guide. Is it XPG3, XPG4, or something else? They have changed the meaning of the math library with the various releases.

The reference will be checked and possibly changed.

83) [major] Page 66, section A.9.3, first paragraph. The idea that an integer, just because it is in floating-point format, is not an integer, needs to be removed. Once that is done, then there are special cases that need to be added. For example, POWER( -3.0, 3.0 ) should be -27.0, not bad_argument.

REJECTED

The only operation specification affected by this request would be the 'power' operations. However, for good reasons, we follow Ada here. For the power operations, the one with a floating point second argument is to be invalid for all negative first arguments, since floating point values usually are approximate, and neighbouring argument values will return invalid. For the case that the second argument is known to be an exact integer, the power operation with integer type second argument is specified (power_FI), which will compute as you suggest for negative first arguments.

Here is the IEC 559 specification adopted by WG14/X3J11 into C9X, the revision of C currently in progress:

pow(x, +/- 0) returns 1 for any x.

pow(x, +INFINITY) returns +INFINITY for |x| > 1.

pow(x, +INFINITY) returns +0 for |x| < 1.

pow(x, -INFINITY) returns +0 for |x| > 1.

pow(x, -INFINITY) returns +INFINITY for |x| < 1.

pow(+INFINITY, y) returns +INFINITY for y > 0.

pow(+INFINITY, y) returns +0 for y < 0.

pow(-INFINITY, y) returns -INFINITY for y an odd integer > 0.

pow(-INFINITY, y) returns +INFINITY for y > 0 and not an odd integer.

pow(-INFINITY, y) returns -0 for y an odd integer < 0.

pow(-INFINITY, y) returns +0 for y < 0 and not an odd integer.

pow(x, y) returns one of its NaN arguments if y is a NaN, or if x is a

NaN and y is nonzero.

pow(+/- 1, +/- INFINITY) returns a NaN and raises the invalid exception.

pow(x, y) returns a NaN and raises the invalid exception for finite x < 0 and finite nonintegral y.

pow(+/- 0, y) returns +/- INFINITY and raises the divide-by-zero exception for y an odd integer < 0.

pow(+/- 0, y) returns +INFINITY and raises the divide-by-zero exception

for y < 0 and not an odd integer.

pow(+/- 0, y) returns +/- 0 for y an odd integer > 0.

pow(+/- 0, y) returns +0 for y > 0 and not an odd integer.

The specifications for the power operations will be corrected and completed, but not exactly along these lines. See also the reply to your comment 18 and above. The specification you have given above is an amalgamation of specifications for power_F and power_FI, wich we will keep separate.

84) [minor] Page 74, section A.15.1. Change "exceeds maxint" to "exceeds maxint+1".

ACCEPTED

85) [minor] Page 74, section A.15.2. Change "minint exceeds" to "minint-1 exceeds".

ACCEPTED

86) [typo] Page 74, section A.15.3. The second paragraph should be

section A.15.4 TRUNCATE.

ACCEPTED

87) [typo] Pages 74 and 75. Increase the number of each section after A.15.3 by 1.

ACCEPTED

The typos will be fixed. Maybe the texts here will be rewritten.

88) [minor] Page 74, old sections A.15.4, A.15.5, A.15.6, A.15.7. fmax need not always be an integer. The IBM 1620 had a two decimal digit exponent and variable length significand that could be longer than decimal 99 digits (as we recall).

REJECTED

Those floating point types do not conform to LIA-1. For LIA-1 conforming floating point types, fmax is integral (and the significand is of fixed length).

89) [minor] The statement that "the argument must lie between two integral values" is false. Consider the exact values 0.0 and 1.0; neither is between.

ACCEPTED

The text will be reformulated, if at all kept.

90) [typo] Page 75, old section A.15.8. Change "th%" to "the" and fix the fmaxG where the G overlaps the x.

The editor cannot see this. There is no % there, there is no x there, except within words, and they look ok.

91) [minor] Page 75, old sections A.15.8, A.15.9, A.15.10, A.15.11. Need to add words to exclude zero from raising underflow in the last sentence.

ACCEPTED

Will be fixed. The problem is more complex than that, however. A value that can be exactly converted to a denormal result, should not always indicate underflow. Cmp. IEC 559/IEEE 754.

92) [minor] Page 75, section A.16. Change "All language" to "Most language". ALGOL-60 has no I/O. Change the first "I/O" to "Input/Output (I/O)".

REJECTED (but "I/O" will be expanded)

Algol 60 is no longer an ISO std... Algol did have numeric literals, and this clause applies to literals as well. (B.t.w. Algol 60 did have I/O, but it was "implementation defined".)

93) [minor] Page 76, section A.18, 1st paragraph. Remove "and/or range" or explain how using one gets more exponent range by using doubled representation. Change "highest" to "most precise".

ACCEPTED

"and/or range" will be reformulated. Some operations extend the range of values for an integer type, other operations extend the precision (in some sense) of the values of a floating point type. "highest" will be changed to "most precise".

94) [typo] Page 77, section A.18.2.3. Change "MULHI" to "MULLO".

REJECTED

mulhi_F should be mul_F.

95) [typo] Page 77, section A.18.2.4. Change "DIVHI" to "DIVLO".

REJECTED

divhi_F should be div_F.

96) [minor] Page 79, section A.20.1. Remove "It must never produce an underflow." Remove "This claim is not always valid."

fist part is ACCEPTED, second part is REJECTED

...since the claim in question is actually not ALWAYS valid, as the sentence says, even if it may often be valid.

97) [minor] Page 99, section C, item [1]. Add "second edition" to the IEC 559 reference. Change "854-1987" to "754-1985".

ACCEPTED, but date of latest revision will be double-checked.

98) [minor] Page 99, section C, item [14]. We believe that the 1994 standard has been published, so remove "(to be published)".

ACCEPTED: ISO/IEC 10514-1:1996 .

99) [minor] Page 100, section C. Add item [23.5] ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic.

ACCEPTED

100) [info] Page 100, section C, item [28]. There is a corrected version of that Handbook of Mathematical Functions that has been published by Dover.

ACCEPTED

101) [minor] Page 101, section C, item [37]. This appears to be two references in one and needs to be split into two. The Sorenson/Tang reference appears to be correct in the first draft of LIA-2. In addition, the Floating-Point C Extensions (FPCE) reference is out of date. It should be: Numerical C Technical Report, X3/TR-17:1995.

ACCEPTED

- ---------------------end of Germany comments ----------------------

US NATIONAL BODY VOTE ON FCD BALLOT FOR ISO/IEC 10967-2.2:1996

The US national body votes to 'Disapprove' the ballot for Final Commitee Draft (FCD) for ISO/IEC 10967-2.2:1996(E), Second edition, December, 1996. Information technology -- Language independent arithmetic -- Part 2: Elementary numerical functions. That document will be called LIA-2 in the rest of this document.

The following are the US comments in support of the vote to Disapprove. The comments have been classified into four categories and are presented by category:

- - M [major] These are major technical errors or ambiguities that are the cause of the US vote to 'Disapprove';

- - m [minor] These are technical errors or ambiguities that the US would like to see resolved, but did not cause the US to vote 'No';

- - E [editorial] These are typographical or obviously very minor errors;

- - I [info] These are noted for informational purposes only.

If the M category comments can be resolved, the US reserves the right to change its 'No' vote to 'Yes'.

Since the US comments is a subset of the German comments, WG11 refers to the replies to the German comments, rather than repeating the replies in a slightly different order.

M [MAJOR] COMMENTS

[M] Page 9, section 5.2 Definition. The definitions given in sections 8 and higher are not consistent. Some exclude all domains where exceptions happen, others exclude some of the domain where exceptions happen. Contrast 11.1 sin() and 11.7 tan(). You may need to add a paragraph to this section explaining the intent.

[M] Page 9, section 5.2, item b). Change the "OP" in the exponent to lower case so that the error is calculated in terms of the correct mathematical result, instead of the computed result. The program can still estimate the error based upon the calculated value, but the error limits for conformance must be defined in terms of the true mathematical value. It matters the most when the true value is just below a power of the radix and the calculated value is just above that same power of the radix. Using the calculated value to compute the error bound results in an error "radix" times as large as using the true value.

[M] Page 10, section 5.3. It is not clear if axioms and the functions are dependent upon rounding or independent of the rounding. For example, if the user changes the rounding to plus infinity, calls a function, then changes the rounding to minus infinity and calls the same function with the same argument (so as to get the bounds of the result), must the function honor the rounding? May the function honor the rounding? Or, must the function be independent of the rounding? If rounding matters, than many of the axioms in sections 8 and higher are false, in particular, those that state that f(x) is x if x is small.

[M] Page 10, section 5.5, 2nd paragraph. What is the meaning of "each such operation provided by an implementation must also be provided at lower accuracy and higher performance."? This is new with the second edition. It also is a contradiction to the Introduction on page x where it is a recommendation. In reading the response to the Japan's comments to the first edition "It is intended that an implementation provide a library of reasonably high accuracy, and also provide one of lower accuracy, with error bounds three or four times greater than those for high accuracy.", it appears that there is supposed to be an accurate and slow library and a sloppy and fast library. That intent needs to be made clearer. For example, is the lower accuracy library still required to meet the accuracy requirement of LIA-2? How does the program select the accurate or sloppy version? Is it done at compile time, link time or at runtime?

[M] Page 11, section 6, 4th paragraph. First choice is to remove the entire paragraph, second choice is to change it so that functions may optionally signal underflow for denormal arguments. It appears that you tried to apply the idea that f(x) is x (not underflow) for denormal x to the rest of the document, but you did not do a consistent job. For example, you say sin(x) for a denormal is not underflow, yet sinh(x) and arcsin(x) for a denormal are underflow.

[M] Page 16, section 9.3, Exceptions. Rewrite the case of x < 0 into cases that cover integers and non-integers.POWER( -2.0, 2.0 ) and POWER( -3.0, 3.0 ) are well defined. The US disagrees with the assumption in A.9.3 that integer floating-point values are approximate.

[M] Page 18, section 10.1, IEC 559 Special Values. Remove the bad_argument exception for ln(+INF). Make it consistent with sqrt().

[M] Page 19, section 10.2, IEC 559 Special Values. Remove the bad_argument exception for ln1p(+INF). Make it consistent with sqrt().

[M] Page 19, section 10.3, IEC 559 Special Values. Remove the bad_argument from log(+inf,w) = bad_argument (+inf) case. Make it consistent with sqrt().

[M] Page 20, section 10.4.1, IEC 559 Special Values. Remove the bad_argument exception for log_2(+INF). Make it consistent with sqrt().

[M] Page 20, section 10.4.2, IEC 559 Special Values. Remove the bad_argument exception for log_10(+INF). Make it consistent with sqrt().

[M] Page 32, section 12.8, IEC 559 Special Values. Remove the bad_argument exception for arctan(+INF,w) and replace it with pi/2. Make it consistent with sqrt().

[M] Page 32, section 12.8, IEC 559 Special Values. Remove the bad_argument exception for arctan(-INF,w) and replace it with -pi/2. Make it consistent with sqrt().

[M] Page 34, section 12.14, IEC 559 Special Values. Remove the bad_argument exception for arccot(+INF,w) and replace it with +0. Make it consistent with sqrt().

[M] Page 34, section 12.14, IEC 559 Special Values. Remove the bad_argument exception for arccot(-INF,w) and replace it with -0. Make it consistent with sqrt().

[M] Page 62, section A.5.2. Change "OP(x,...)" to "op(x,...)" in the exponent of r for the error bound so that it computes the error in terms of the mathematical function and not the computer function.

[M] Page 65, section A.6. The idea that some underflows are better than other underflows, that is, some should be acknowledged but others ignored, should either be removed or made optional. Also, there is a factual error: Underflow can happen for a normal as well as a denormal input argument. Consider, sin(x), where x is the smallest normalized number. Since the series for sin() is x - x**3/3! ..., the mathematical result is a little less than the input, so in round to zero or round to minus infinity, the computed result is the largest denormal and hence underflow.

[M] Page 65, section A.8.1, 2nd paragraph. The idea that some infinities are different from other infinities, that is, +inf from addition is different from +inf from multiplication is different from +inf from divide by zero, needs to be removed. It sounds like you want the math functions to check the exception flags and treat an input of +inf and overflow different from an input of +inf and divide-by-zero.

[M] Page 66, section A.9.3, first paragraph. The idea that an integer, just because it is in floating-point format, is not an integer, needs to be removed. Once that is done, then there are special cases that need to be added. For example, POWER( -3.0, 3.0 ) should be -27.0, not bad_argument.

Here is the IEC 559 specification adopted by WG14/X3J11 into C9X, the revision of C currently in progress:

pow(x, +/- 0) returns 1 for any x.

pow(x, +INFINITY) returns +INFINITY for |x| > 1. pow(x, +INFINITY) returns +0 for |x| < 1. pow(x, -INFINITY) returns +0 for |x| > 1.

pow(x,- -INFINITY) returns +INFINITY for |x| < 1. pow(+INFINITY, y) returns +INFINITY for y > 0.

pow(+INFINITY, y) returns +0 for y < 0.

pow(-INFINITY, y) returns -INFINITY for y an odd integer > 0.

pow(-INFINITY, y) returns +INFINITY for y > 0 and not an odd integer.

pow(-INFINITY, y) returns -0 for y an odd integer < 0. pow(-INFINITY, y)

returns +0 for y < 0 and not an odd integer. pow(x, y) returns one of its NaN arguments if y is a NaN, or if x is a NaN and y is nonzero.

pow(+/- 1, +/- INFINITY) returns a NaN and raises the invalid exception.

pow(x, y) returns a NaN and raises the invalid exception for finite x < 0 and finite nonintegral y.

pow(+/- 0, y) returns +/- INFINITY and raises the divide-by-zero exception for y an odd integer < 0.

pow(+/- 0, y) returns +INFINITY and raises the divide-by-zero exception for y < 0 and not an odd integer.

pow(+/- 0, y) returns +/- 0 for y an odd integer > 0.

pow(+/- 0, y) returns +0 for y > 0 and not an odd integer.

m [MINOR] COMMENTS

[m] Page ix. Please add a sentence saying if notes are normative or for information only.

[m] Page x, last paragraph, last sentence. How does a program select the library best suited to its application? What parameters are used to make this selection? Our impression is there is one math library that conforms to LIA-2.

[m] Page 1, section 1.1, 2nd paragraph, change "exceptional input value" to "IEC 559 special value" or "IEC 559 continuation value".

[m] Page 2, section 2.1 and following. Change "operations" to "numerical functions". This document is about numerical functions, not arithmetic operations.

[m] Page 2, section 2.2, 1st paragraph, what does ", and no others" mean? Is an input or output operation (which most languages have) considered part of "others"?

[m] Page 7, item 22. Change "digits in the fraction" to "radix-r digits in the fraction f in 0.f*r**e". We are used to scientific notation where there is one digit before the decimal point and several fraction digits after the decimal point.

[m] Page 8, item 34. Change "normalized value x" to "normalized value x (0.f*r**p)".

[m] Page 8, section 5, 3rd paragraph. Change "error limit, and extensions" to "error limit, and IEC 559 special values".

[m] Page 11, section 5.6 title. Change "Extensions" to "IEC 559 Special Values".

[m] Page 11, section 6, 6th paragraph. Change "signaling NaN as an input, then a bad_argument notification shall result" to "signaling NaN as an input, then a bad_argument notification shall result with a quiet NaN as the continuation value".

[m] Page 11, section 6, 6th paragraph. Add "Functions with one quiet NaN input return that same quiet NaN. Functions with multiple quiet NaN inputs return one of the input quiet NaNs."

[m] Page 15, section 9.2, in the Note. Remove the word "only".

[m] Page 17, section 9.6, title. Change "known base" to "integer base".

[m] Page 17, section 9.6.1 and 9.6.2, Axioms. The domains are not consistent. One mentions fmax, the other fmin. It seems that the domains should be the same domain as in the Definition section.

[m] Page 17, section 9.6.1, section Exceptions. Change "x <=" to "x <". On a binary machine, log2(fminN) is an exact integer, so underflow will not happen for exp2(log2(fminN)).

[m] Page 18, section 9.6.2, section Exceptions. Change "x <=" to "x <". On a decimal machine, log10(fminN) is an exact integer, so underflow will not happen for exp10(log10(fminN)).

[m] Page 19, section 10.2, in the Note. Remove the word "only".

[m] Page 19, section 10.3, IEC 559 Special Values. Remove, or explain better, the log(1,w) = bad_argument case. log of 1 for any valid base is 0.

[m] Page 19, section 10.4, title. Change "known base" to "integer base".

[m] Page 19, section 10.4.1, many sections. Replace lower case "log_2" with "log2" where the 2 is a subscript.

[m] Page 20, section 10.4.2, many sections. Replace lower case "log_10" with "log10" where the 10 is a subscript.

[m] Pages 21 to 28, sections 11.1 to 11.18, Exceptions. Many of the definitions of underflow are in terms of fmin which should be fminN.

[m] Page 21, section 11.1, Exceptions. For the underflow case, change the "1 <= |x|" to "0 <= |x|".

[m] Page 21, section 11.2, Axioms. Add SIN(u/2,u) = 0.0

[m] Page 21, section 11.2, Exceptions. For the underflow case, change the "u/8 <= |x|" to "0 <= |x|".

[m] Page 29, section 12.1, Axioms. Change "|x| <= fmax" to "|x| <= 1".

[m] Page 30, section IEC 559 Special Values. Here and in many following functions, there is a function N() that is not defined (that we can find). We assume it is nearest rounding.

[m] Page 43, section 15.3, Definition. Change "<= x <=" to "< x <". Since you allow round to nearest to round up or down, maxint + 1/2 could round to maxint + 1 which is overflow.

[m] Page 45, section 15.9, Exceptions. Change it so that floor(0.0) is 0.0, not underflow. For example, if 0 < |x| < fminNG.

[m] Page 45, section 15.10, Exceptions. Change it so that ceiling(0.0) is 0.0, not underflow.

[m] Page 45, section 15.10, IEC 559 Special Values. Why are -0, infinity, and NaN allowed to be in one floating type (F), but not another floating type (G)? Why is that case allowed for here, but not in DPROD (section 19.1)?

[m] Page 45, section 15.11, Exceptions. Change it so that nearest(0.0) is 0.0, not underflow.

[m] Page 46, section 15.12, Exceptions. Change it so that truncate(0.0) is 0.0, not underflow.

[m] Page 48, sections 16.2.1 to 16.2.4, IEC Special Values. Add "f(SNaN) causes no notification". Need some way to print SNaNs.

[m] Page 49, section 16.3, 2nd paragraph. Since compile time literal conversion and runtime input conversion need not be identical, there should be an error bound on the difference between them.

[m] Page 51, section 18, first paragraph. Change "2p-3" to "2p" or explain why the -3.

[m] Page 52, section 18.2.1, IEC 559 Special Values. Change the bad_argument cases to be 0.

[m] Page 53, section 18.2.2, IEC 559 Special Values. Change the bad_argument cases to be 0.

[m] Page 53, section 18.2.3, IEC 559 Special Values. Change the bad_argument cases to be 0.

[m] Page 53, section 18.2.4, Error limit. What is "xhi(x,y)"? Explain or correct if in error.

[m] Page 54, section 18.2.5, IEC 559 Special Values. Change the bad_argument cases to be 0.

[m] Page 56, section 19.2, IEC 559 Special Values. Change the bad_argument cases to be 0.

[m] Page 57, section 20.1. The text description says that underflow does not occur, yet underflow shows up in the exceptions section.

[m] Page 57, section 20.3, IEC 559 Special Values. Remove the DIM(NaN,w) case.

[m] Page 58, new section. Please add an ulp(x) function that returns the value of an ulp of the argument x. ulp(small) can underflow if denormals are not representable. ulp(0.0) is bad_argument. ulp(infinity) is bad_argument. ulp(-x) == ulp(x).

[m] Page 59, section A, Acknowledgements. Remove the X3 from X3T2. This may need to be elsewhere in the document.

[m] Page 59, Add WG14/J11 to the list of standards committees that provided advice.

[m] Page 59, section A, Project milestones. Change "August 1996" to "December 1996".

[m] Page 63, section A.5.5. Remove "It should be mentioned that an implementation can usually provide numerical operations with higher accuracy than that associated with the underlying basic arithmetic operations." How can "sin()" be more accurate than "+"?

[m] Page 63, section A.5.6, 2nd paragraph. The statement "LIA-2 requires conformance to IEC 559 by implementations which provide these special values" needs to be changed. Just because an implementation supports -0, +/- infinity, and NaN, does not mean that it is capable of conforming to IEC 559. There are systems that do not support denormal numbers, but do have those special values. There are systems that provide Signaling NaNs, but no Quiet NaNs, but do the rest.

[m] Page 64, section A.5.6.4, 1st paragraph. Remove "(unjustified)".

[m] Page 66, section A.9. Add a reference to a new entry in the bibliography to which X/Open Portability Guide. Is it XPG3, XPG4, or something else? They have changed the meaning of the math library with the various releases.

[m] Page 74, section A.15.1. Change "exceeds maxint" to "exceeds maxint+1".

[m] Page 74, section A.15.2. Change "minint exceeds" to "minint-1 exceeds".

[m] Page 74, old sections A.15.4, A.15.5, A.15.6, A.15.7. fmax need not always be an integer. The IBM 1620 had a two decimal digit exponent and variable length significand that could be longer than decimal 99 digits (as we recall).

[m] The statement that "the argument must lie between two integral values" is false. Consider the exact values 0.0 and 1.0; neither is between.

[m] Page 75, old sections A.15.8, A.15.9, A.15.10, A.15.11. Need to add words to exclude zero from raising underflow in the last sentence.

[m] Page 75, section A.16. Change "All language" to "Most language". ALGOL-60 has no I/O. Change the first "I/O" to "Input/Output (I/O)".

[m] Page 76, section A.18, 1st paragraph. Remove "and/or range" or explain how using one gets more exponent range by using doubled representation. Change "highest" to "most precise".

[m] Page 79, section A.20.1. Remove "It must never produce an underflow." Remove "This claim is not always valid."

[m] Page 99, section C, item [1]. Add "second edition" to the IEC 559 reference. Change "854-1987" to "754-1985".

[m] Page 99, section C, item [14]. We believe that the 1994 standard has been published, so remove "(to be published)".

[m] Page 100, section C. Add item [23.5] ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic.

[m] Page 101, section C, item [37]. This appears to be two references in one and needs to be split into two. The Sorenson/Tang reference appears to be correct in the first draft of LIA-2. In addition, the Floating-Point C Extensions (FPCE) reference is out of date. It should be: Numerical C Technical Report, X3/TR-17:1995.

E [EDITORIAL] COMMENTS

[E] Page 19, section 10.3, before Signature. What is "plia2.tex"?

[E] Page 19, section 10.3, IEC 559 Special Values. What is the ">/" symbol in "if w >/ 1"? Should it be w not element of F or w <= 1?

[E] Page 22, section 11.5, Axioms. The exponent "(-1-p/2)" needs to be fixed so that it is all an exponent.

[E] Page 28, section 11.17, Exceptions. "if ( 2|u," is missing some text.

[E] Page 29, section 12.1, Signature. Change "bad_argument underflow" to "bad_argument, underflow".

[E] Page 42, section 15.1, title. Change "Convert to float" to "Convert to integer".

[E] Page 45, section 15.10 and higher, make the "if"s line up vertically.

[E] Page 51, sections 17.6 and 17.8, IEC Special Values. Add some spaces before F(w,v) = F(v,w) and after the +INF.

[E] Page 57, section 20.1, IEC 559 Special Values. Change "(w.v)" to "(w,v)".

[E] Page 60, section A.2, last line. Change "LIA=2" to "LIA-2".

[E] Page 61, section A.5.2. Change "log" to "LOG".

[E] Page 63, section A.5.6, 3rd paragraph. The reference to [37] is wrong because reference [37] appears to be two documents combined into one item.

[E] Page 74, section A.15.3. The second paragraph should be section A.15.4 TRUNCATE.

[E] Pages 74 and 75. Increase the number of each section after A.15.3 by 1.

[E] Page 75, old section A.15.8. Change "th%" to "the" and fix the fmaxG where the G overlaps the x.

[E] Page 77, section A.18.2.3. Change "MULHI" to "MULLO".

[E] Page 77, section A.18.2.4. Change "DIVHI" to "DIVLO".

I [INFORMATIONAL] COMMENTS

[I] Page 100, section C, item [28]. There is a corrected version of that Handbook of Mathematical Functions that has been published by Dover.

*- ------------------end of USA comments -------------------------*