From rinehuls@Radix.Net Sat Jan 30 00:54:16 1999 Received: from mail1.radix.net (mail1.radix.net [209.48.224.31]) by dkuug.dk (8.8.7/8.8.7) with ESMTP id AAA19844; Sat, 30 Jan 1999 00:54:13 +0100 (CET) (envelope-from rinehuls@Radix.Net) Received: from saltmine.radix.net (saltmine.radix.net [209.48.224.40]) by mail1.radix.net (8.9.1/8.9.1) with SMTP id SAA05764; Fri, 29 Jan 1999 18:54:10 -0500 (EST) Date: Fri, 29 Jan 1999 18:52:36 -0500 (EST) From: William Rinehuls To: sc22docs@dkuug.dk cc: keld simonsen Subject: SC22 N2879 - Vote Summary on CD 10967-2 - Elementary Numeric Functions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ____________________ beginning of title page _________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2879 TITLE: Summary of Voting on CD Ballot for CD 10967-2: Information technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions (Third CD Ballot) DATE ASSIGNED: 1999-01-29 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: JTC 1.22.33 STATUS: WG11 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the CD. ACTION IDENTIFIER: FYI DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC22 N2824 DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@radix.net __________ end of title page; beginning of overall summary __________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2824 Circulated by: JTC 1/SC22 Circulation Date: 1998-10-12 Closing Date: 1999-01-26 TITLE: CD Ballot for CD 10967-2: Information technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions (Third CD Ballot) ---------------------------------------------------------------------- The following responses have been received on the subject of approval: "P" Members supporting approval without comments 8 "P" Members supporting approval with comments 1 "P" Members not supporting approval 4 "P" Members abstaining 2 "P" Members not voting 7 "O" Members supporting approval without comment 1 "O" Members supporting approval with comments 1 ------------------------------------------------------------------- Secretariat Action: WG11 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the CD. The comment accompanying the abstention vote from Denmark was: "Lack of Danish expertise." The comments accompanying the negative votes from France, Germany, Japan and the United Kingdom are attached, along with the comments accompanying the affirmative votes from Sweden and the United States of America. ______________ end of overall summary; beginning of detail summary _____ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PROJECT NO: JTC 1.22.33 SUBJECT: CD Ballot for CD 10967-2: Information technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions (Third CD Ballot) Reference Document No: N2824 Ballot Document No: N2824 Circulation Date: 1998-10-12 Closing Date: 1999-01-26 Circulated To: SC22 P, O, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria ( ) ( ) ( ) ( ) (X) Belgium ( ) ( ) ( ) ( ) (X) Brazil (X) ( ) ( ) ( ) ( ) Canada ( ) ( ) (X) ( ) ( ) China (X) ( ) ( ) ( ) ( ) Czech Republic ( ) ( ) ( ) ( ) (X) Denmark ( ) ( ) (X) (X) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France ( ) (X) ( ) (X) ( ) Germany ( ) (X) ( ) (X) ( ) Ireland (X) ( ) ( ) ( ) ( ) Japan ( ) (X) ( ) (X) ( ) Netherlands (X) ( ) ( ) ( ) ( ) Norway (X) ( ) ( ) ( ) ( ) Romania ( ) ( ) ( ) ( ) (X) Russian Federation ( ) ( ) ( ) ( ) (X) Slovenia ( ) ( ) ( ) ( ) (X) UK ( ) (X) ( ) (X) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA (X) ( ) ( ) (X) ( ) 'O' Members Voting Korea Republic (X) ( ) ( ) ( ) ( ) Sweden (X) ( ) ( ) (X) ( ) ___ end of detail summary; beginning of France comments ____________ TITLE: Ballot comments on document ISO/IEC JTC1/SC22N2824 : CD 10967-2: Information technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions (Third CD Ballot) SOURCE: AFNOR France votes NO to document SC22/WG11 CD 10967-2. The vote will be reversed if the following comments are satisfactorily resolved. Comment 1. Committee Draft subsection: C.4 Category: Request for rewording (minor editorial) Title: Separation of C binding from C++ binding Rationale: This proposed rewording is a consequence of comment 2. Proposed change: a) This subsection should read "C" (and not "C and C++") b) For reasons exposed in comment 2, we proposed that the last sentence (refering to C++) of the first paragraph of section C.4 be removed. Comment 2. Committee Draft Section: C Category: subsection that should be included (major editorial) Title: Proposal for a C++ binding Rationale: C++ is a quite different language from C in its features, namely type safety, name space management and overloading. Requiring C++ to have the same binding is not necessary and unjustified. C++ has its own mecanism to maintain (library functions) compatibility with C. Proposed change: We feel that the following subsection should be included as C++ binding. =================== cut here ====================== C.??? C++ The programming language C++ is defined by ISO/IEC 14882:1998, Information Technology -- Programming Languages - C++. An implementation should follow all the requirements of LIA-2 unless otherwise specified by this language binding. The operations or parameters marked "[dag]" are not part of the language and should be provided by an implementation that wishes to conform to the LIA-2 for that operation. For each of the marked items a suggested identfier is provided. LIA-2 recommands that all identifers suggested therein be defined in the namespace std::math. The C++ datatype "bool" corresponds to the LIA-1 datatype "Boolean". Every implementation of C++ has integral datatypes "int", "long int", "unsigned int" and "unsigned long int" which (can) conform to LIA-1. C++ has three floating point datatypes that (can) conform to LIA-1: "float", "double", "long double". The additional integer operations are listed below along with the syntax to invoke them: minI(x, y) min(x, y) maxI(x, y) max(x, y) min_seqI(xs) min_element(xs_start, xs_end) max_seqI(xs) max_element(xs_start, xs_end) dimI(x, y) positive_difference(x, y) [dag] sqrtI(x) sqrt(x) [dag] powerI(x, y) power(x, y) [dag] dividesI(x, y) divides(x, y) [dag] evenI(x) x % 2 == 0 oddI(x) x % 2 != 0 gcdI(x, y) gcd(x, y) [dag] lcmI(x, y) lcm(x, y) [dag] gcd_seqI(xs) gcd(xs_start, xs_end) [dag] lcm_seqI lcm(xs_start, xs_end) [dag] add_wrapI(x, y) add_wrap(x, y) [dag] add_ovI(x, y) add_overflow(x, y) [dag] sub_wrapI(x, y) sub_wrap(x, y) [dag] sub_ovI(x, y) sub_overflow(x, y) [dag] mul_wrapI(x, y) mul_wrap(x, y) [dag] mul_ovI(x, y) mul_overflow(x, y) [dag] where x and y are expressions of type INT and where xs is expression of type a sequence (list, deque, vector, valarray) or INT[]. xs_start and xs_end are expressions denoting the beginning and one past end iterators of xs. The additional non-transcendental floating point operations are listed below, along with the syntax used to invoke them: minF(x, y) max(x, y) maxF(x, y) max(x, y) min_seqF(xs) min(xs_start, xs_end) max_seqF(xs) max(xs_start, xs_end) floorF(x) floor(x) roundingF(x) round(x) [dag] ceilingF(x) ceil(x) dimF(x, y) positive_difference(x, y) [dag] add3F(x, y, z) add(x, y, z) [dag] sumF(sx) accumulate(xs_start, xs_end, 0.) dprodF->F'(x, y) ???(x, y) [dag] mul_addF(x, y, z) mul_add(x, y, z) [dag] iremF(x, y) remainder(x, y) [dag] sqrtF(x) sqrt(x) rsqrtF(x) reciprocal_sqrt(x) [dag] add_loF(x, y) add_low(x, y) [dag] sub_loF(x, y) sub_low(x, y) [dag] div_restF(x, y) div_rest(x, y) [dag] sqrt_restF(x) sqrt_rest(x) [dag] where x and y are expressions of type FLT and where xs is expression of type a sequence (list, deque, vector, valarray) or FLT[]. xs_start and xs_end are expressions denoting the beginning and one past end iterators of xs. The parameters for operations for approximating real valued transcendal functions can be accessed by the following syntax: max_err_hypothF err_hypothenuse() [dag] max_err_expF err_exp() [dag] max_err_powerF(b, x) err_power(b, x) [dag] max_err_sinhF(x) err_sinh(x) [dag] max_err_tanhF(x) err_tanh(x) [dag] big_radian_angleF(x) err_radian_angle(x) [dag] max_err_sinF(x) err_sin(x) [dag] max_err_tanF(x) err_tan(x) [dag] big_angleF big_angle() [dag] max_err_sinuF(u) err_sin_cycle(u) [dag] max_err_tanhF(u) err_tan_cycle(u) [dag] where b, x and u are expressions of type FLT. << The rest of this subsection is identical to the corresponding part of the subsection titled "Java". >> =================== cut here ====================== Comment 3. Committee Draft subsection: 1.1 Category: request for rewording (minor editorial) Title: reference for bindings Rationale: This proposal is a logical consequence of comment 2. Proposed change: We propose that the paragraph 1.2p3 be rephrased as follow: ISO/IEC 10967-2 covers most numerical functions required by the ISO standards for Ada, Basic, C, C++, Fortran, Extented Pascal, ISLisp, and PL/I. In particular, specifications are provided for... _____ end of France comments; beginning of Germany comments _________ German vote on ISO/IEC CD 10967-2: Information technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions Reference No. ISO/IEC JTC1/SC22 N 2824 Germany votes: NO with comments The document still contains many editorial and English language errors such as incorrect usage of the singular or the plural, of technical or mathematical terms (e.g. monotonous instead of monotonic (function)), typos and misprints as well as structural errors (e.g. chapter structure of sections 5.2.7 - 8 does not match Annex A where 5.2.7 - 10 appear). Germany still believes that the problem of summation of many terms, especially of floating-point numbers or of simple products thereof (i.e. the dot product) is not addressed adequately and poses a fundamental problem in many numerical applications. However, Germany has noticed improvements in this area and is willing to provide assistance in this matter. Also, some references are out of date, e.g. to the Fortran standard. The new Fortran standard is Fortran 95, published in 1997. It should be cited throughout, and adjustments should be made in the text. _____ end of Germany comments; beginning of Japan comments _________ CD Ballot (SC22 N2824, due 1999-01-26) ISO/IEC 10967-2, Information technology - Language independent arithmetic - Part 2: Elementary numerical functions Japan disapproves the draft for reasons shown below. --------------------------------------------------------------------------- 1. Error limit The definition of conformity to this standard has been improved, but there still remain some points to be revised. We understand that the error limits of each function should be defined by each implementation, not by binding standards. This interpretation is supported by the descriptions in Clause 8 and Annex B. However, it would also be possible to interpret that the error limits may be defined by binding standards. Error limits defined for Ada numeric functions are rather loose than those defined in this standard. This leads to an unfortunate consequence that Ada implementations conforming to the Ada standard does not necessarily conform to this standard. We have heard that, in order to escape from this situation, the binding standard for Ada can itself define error limits larger than those defined in this standard. We cannot deduce this explanation from the text of the standard. If this explanation is a right one, it should be explicitly mentioned in the text. In any case, it should be clearly defined whether a binding standard can define error limits or not. In A.2, it is suggested that a binding standard should define error limits, but this can only be taken as informative. The same thing should be stated in the normative part of the standard. In the fourth paragraph of Clause 2, the term "conflict between a binding standard and this part of ISO/IEC 10967-2" appears. It is not clear what type of conflict is allowed. We consider that some "upper bound" of conflict is necessary, since without such upper bound, a binding standard can define anything totally disregarding the definitions in this standard. 2. Definition of F The symbol F is used throughout the document to represent a "floating point datatype". There is some confusion on the usage of F: (a) In each function definition, F looks to represent a subset of R. A condition clause "if x in F" should read "if x is not a special value". This standpoint is stated in the definition of "arithmetic datatype" (4.2). (b) In other places, F looks to represent the type which may contain special values. See the second paragraph of 5.2. Usage (a) is the fundamental one, and is the way adopted in LIA-1 and the previous versions of LIA-2. The document should clearly state this standpoint and avoid any ambiguous usage of F. We suggest possible improvement below, with <> and to the text. == suggested changes in wording ================================== 4.1 Symbols The following symbols are defined in ISO/IEC 10967-1:1994, and used in this part <>. ... The following symbols represent <> values defined in IEC 559... ... These <> are not part of the <> set F, but if iec_599F has the value true, . <> 4.2 Definitions ... arithmetic datatype: A datatype whose values are member of Z, R or C. .... signature: A summary of information about an operation or function. ... The signature addI: IxI -> I U {integer_overflow} .... <> 5.1 Additional basic integer operations ... I is an integer datatype conforming to ISO/IEC 10967-1<<:1994>>. Integer types conforming to ISO/IEC 10967-1<<:1994>> usually do not any NaN or infinity values, even though they may do so. Therefore this clause has no specification for such values as arguments. ... <> 5.2 Additional basic floating point operations ... F is a floating point datatype conforming to ISO/IEC 10967<<:1994>>. Floating point datatypes conforming to ISO/IEC 10967-1<<:1994>> usually do NaN and infinity values. Therefore, in this clause . == end of suggested changes in wording =========================== 3. minor errors We found many minor errors in the standard. We judge that this CD text is still immature, and should be improved before going to DIS stage. Foreword: According to the ISO home page, the full name of ISO is "the International Organization for Standardization". They do not use British spelling for the name of the organization. Foreword: The scope of SC22 should be written correctly. 1.1: The current wording "C/C++" implies that C and C++ are compatible languages. This is not true, and they should be written as "C, C++"". 1.1: An "and" should be added at the end of (e). 3.: The second word of the title should be written in lower case. 4.1: The operator "|" is not enumerated in the list of notations. 4.1: "it" should be changed to "is" in the following sentence. "... difference of conventions it the arccot function.". 4.1: The period after "s2" should be changed to a comma, in "s1 and then s2. Etc.". "Etc" should be changed to "etc". 4.1: The current list of exceptional values is "integer_overflow, floating_overflow, underflow, and undefined". "overflow" should be added to this list. "overflow" is used, for example, in 5.4.5. 4.1: "an" should be changed to "a", in "an highly accurate result". 4.2, precision: "109671" should be changed to "10967-1". 5.1: We cannot understand why the word "additional" is used in the title of this section. 5.1.1, Note 1: The conditions of two alternatives are the same. In what case should we use the first alternative, and in what case the second alternative? 5.1.2, max_seqI: The definition is not complete. What happens if n = 0 and -infinity is available? 5.1.2, min_seqI: The same as above (+infinity). 5.1.4, shift2I: We consider that "invalid" does not occur in this function. 5.1.4: shift10I: The same as above. 5.1.8, gcdI: The definition is not complete. What happens if n = 0 and +infinity is available? 5.1.9, add_ovI: We consider that the conditions I /= Z and I = Z are not adequate. Even if an implementation supports multiple precision arithmetic, an integer type can never cover the whole set of mathematical integers. There might be an argument that an integer datatype I can be any subset of Z conceptually. But, then, what happens if I consists of all the positive values of Z? 5.2.3, dimF: "invalid" should be added to the list of possible output values. 5.2.3: The function rndF is used in the definition of dimF, but we could not find its definition. 5.2.4, Note 3: "handed" should be changed to "handled". 5.2.4: "invalid" should be added to the list of possible output values in the definitions of the following functions. rounding_restF, floor_restF, and ceiling_restF. 5.2.5, iremF: In the eighth alternative, "yis" should be changed to "y is". 5.2.7: "invalid" should be added to the list of possible output values in the definitions of the following functions. add_loF, sub_loF, mul_loF, add3_midF, and mul_add_midF. 5.2.7, add_loF and sub_loF: There are many question marks in the definitions, which means that the definitions are not yet fixed. The third and the fourth alternatives of add_loF are not consistent with those of sub_loF. The symbol "u" appears freely, without definition. 5.2.7, mul_addF: We cannot understand why 0 is handled separately. 5.2.8, sum: We cannot understand why the sum is -0 when n = 0. We think that 0 is quite reasonable. 5.3.3.2, Note 1: There is no predicate verb in the last sentence, which starts with "Something which ...". 5.3.3.2, expm1F: "underflow" is listed in the list of possible output values, but underflow never occurs in this function. 5.3.3.3, powerF: 1^infinity is defined as invalid(1). We think that 1 is quite reasonable in this case. 5.3.3.3, Note 2: Non-overflow conditions is written as "when x = 0 or when x = 1". This is not consistent with the style of Note 1, where the same condition is written as "x in {0, 1}". 5.3.3.4, powerm1F: The result value of the third alternative is -0, but this is not adequate. There may be implementations not supporting this value. We understand that the result value in such cases should be written as negF(0). The same comment applies to 5.2.5, etc. 5.3.3.4, powerm1F: 1^infinity-1 is defined as invalid(0). We think that 0 is quite reasonable in this case. 5.3.3.8, Note: "requireing" should be changed to "requiring". 5.3.3.9, logbaseF: The definition seems to assume that if +infinity is available, so is -infinity. Does this assumption always hold? 5.3.3.9, logbaseF: We consider that the result should be "invalid" when x = +infinity and y is in F, and when x = 1 and y = +infinity. 5.3.3.9, logbaseF: The intersection of the conditions of the 16th and the 17th alternatives is not empty. 5.3.5: Something is wrong in the sentence "... for each the ... functions are ...". 5.3.6, Note: Since this Note gives a definition, it should not be a Note, and should be moved to the main part of the text. We could not deduce the contents of this Note from other definitions in this document. 5.3.6.2, sinF: The second axiom is not correct. pi/4 should be changed to pi/2. 5.3.6.2 -- 5.3.6.8, sinF -- cscF: "invalid" should be added to the list of possible output values for these functions. 5.3.6.9 -- 5.3.6.15, arcsinF -- arccscF, We think that the range of result values should be mentioned in the definitions of reverse trigonometric functions. 5.3.6.11, Note 1: The word "section" is not adequate. "clause" should be used. 5.3.6.11, arcF: There are many question marks in the definition of this function, which means that the definition is not yet fixed. 5.3.6.13, arcctgF: We do not know the mathematical meaning of this function. Is this function necessary? 5.3.7, Note 2: It says that the negative angular unit is not considered. This is not true. In sinuF, for example, the negative angular unit is explicitly considered. 5.3.7.5, tanuF: "-u/2" in the conditions of the first and the second alternatives should be changed to "u/2". When x approaches 180 degrees from the second quadrant, tan(x) approaches to 0 from the negative side. 5.3.9.1: The value "max_error_radF" is used, but we could not find its definition. 5.4, Note 2: "10967does" should be changed to "10967 does". A period should be added after "etc". 5.4.1, Note 1: The first "are" in "both are I and I' are" should be removed. 5.4.1 -- 5.4.6: There are many question marks in the definitions of these functions, which means that the definitions are not yet fixed. 5.4.1 -- 5.4.6: The notion "sNaN without notification" seems strange. Is it different from qNaN? 5.4.4, convert(nearest): "x" in the last alternative should be printed in italic font. 5.4.5: "overflowif" should be changed to "overflow if". 5.4.5, resultD: We feel that the sentence "D is a fixed point type, it cannot conform to LIA-1 ..." is somewhat strange as an English sentence. 5.4.6, convert(nearest): The result value of the sixth and seventh alternatives is "overflow". We consider that this should be changed to "floating_overflow". 5.5.2: An "and" is necessary in the first sentence. It should be inserted between "resultF(x, downF)" and "shall". 5.5.2: It is mandatory for an implementation to prepare a numeral for positive infinity and NaNs. We think that this rule is an over-specification. An implementation supporting these special values but not providing numerals is a reasonable one. 6.: The usage of "so that" in the second line is not a recommended one. It should not be used in a negative statement. 6.: The last sentence in the second paragraph contains two "if"s. 7.: "10967and" should be changed to "10967 and". "of clause 5" should be changed to "in clause 5". A.1: "Sufficient" should be changed to "sufficient". A.4.1: "denormalized" should be changed to "denormalised". The clause A.5.1.7 should be added. The clauses A.5.2.8 and A.5.2.9 should be deleted. The clause A.5.3.1.5 should be deleted. A.5.3.1.5: "thought" should be changed to "though" in "thought they are valid if the ...". "the an approach" should be changed to "the approach". "if" should be changed to "is" in "approach to zero if from ...". The clause A.5.5 should be added. ______ end of Japan comments; beginning of Sweden comments _______ From: Ann Flod (ann.flod@its.sa) Subject: Ballot on SC 22 N 2824 Replacement of the Swedish vote on SC 22 N 2824 and FCD 10967-2. Yes for approval with comments as below: Minot comment: 1. A consistent and practical choice must be made for the by the editor 7-marked specification lines. 2. The bindings examples annex should be better completed for more of the languages than just Ada. Editorial comment: Some lines go a bit far into the margin, and should be wrapped or otherwise shortened. ____ end of Sweden comments; beginning of UK comments _______________ SC22 Letter Ballot N2824 - Approval Ballot for FCD 10967-2 Language Independent Arithmetic - elementary Numeric Functions UK votes NO with comments to CD 10967-2 (LIA-2). STRATEGIC COMMENTS 1 Clause 5.4.6 includes questions to the reviewers concerning the behaviour of convert(... , F to D, x) when x is a signalling NaN. It would help reviewers to have a complete list of such questions, and the arguments in favour of each possibility (it would also help the editor because the questions are more likely to be answered). 2 A large part of this draft defines the values of the arithmetic functions when one or more input arguments is an IEC559 continuation value. This is neither desirable nor necessary. Part 1 of the standard does not define the basic arithmetic operations under such circumstances, and part 2 should not do so either. Does any programming language standard do so? Or is planning to do so? Or has even considered doing so? If there is no candidate for usage of this facility then it should be omitted. TECHNICAL COMMENTS 1 Clause 4.1 defines three separate meanings for [ and ] (square brackets): (i) designating a closed interval, (ii) to delimit a finite sequence of values, (iii) a set of finite sequences. Multiple meanings for square brackets, or any other term/usage, may potentially lead to errors in understanding by readers. NOTE 5 says 'it should be clear from context if [X] is a sequence of one element ...'. If the note can be rewritten to read truthfully 'It is always obvious ...', then perhaps the multiple meanings can be justified, but the UK cannot check this since the source was not available in electronic form. 2 Annex B - Partial conformity belongs in clause 2, not as an informative annex. 3 Clause 5.1.2 - We do not think that -infinity is ever available for an integer type, but if it is, then the definitions leave max_seq and min_seq undefined for the case when n=0 and -infinity is available. 4 Clause 5.1.5 - defines the result as 'round(sqrt(x))'. 'round' should be replaced by a round function (in math font) which itself needs to be defined as a new helper function in 5.1.1. 5 Clause 5.1 states ''Integer datatypes conforming to ISO/IEC 10967-1 usually do not contain any NaN or infinity values'. The integer datatypes defined in ISO/IEC 10967-1 NEVER contain any NaN or infinity values. 6 Clause 5.3.7 Natural logarithm. The ln*(F) function is defined with a Real -> Real signature. This should be Real -> Complex, i.e. R -> Z. Should there be any special consideration when the input argument is a denormalized floating point value? EDITORIAL COMMENTS 1 The draft refers throughout to 'sinus hyperbolicus' rather than 'hyperbolic sine', and similarly with many other functions. This does not appear to the UK to be common usage, nor consistent with LIA-1. 2 Clause 6, para 3 says 'An implementation shall suppress spurious notifications'. What is a 'spurious notification'? The UK is sceptical about the value of suppressing any notification. 3 Clause 6 includes 'NOTE'. It should be 'NOTES'. 4 Claus =e 6 includes a sentence 'The results of ... is ...' instead of 'The results of ... are ...'. 5 Clause 5.4.2 Note 2 Misprint 'ISO/IEC 10967does' 6 Is it necessary for each annex to begin on an odd-numbered page, and thus some blank pages? It was not necessary in 10967-1. 7 Clause 5.3.1.2 The sentence (Those extentions ... .) should be a note, and 'extentions' should be 'extensions'. 8 Clause 5.1.3 What is a 'limited integer type'? Is this what 10967-1 defines as an integer type with bounded = true? OTHER COMMENTS 1. When faced with a new draft standard, it is important that reviewers are provided with a list of what has changed in order to simplify their task. No such list is provided with this draft. It is strongly recommended that such a list is provided with the next versions, although this need not be too detailed as long as it indicates the major areas of change. It is not necessarily appropriate, for example, to provide change bars. 2. Many forms of review are only possible if the source is available, for example, how is a particular word used throughout the standard, writing programs to check completeness and consistency. The source has not been published. It is strongly recommended that an electronic searchable version is provided with the next (paper) version _________ end of UK comments; beginning of USA comments _____________ The US National Body votes to Approve with comments ISO/IEC CD 10967-2, Information Technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions. Please see comments listed below. Global: IEC 559 has been renumbered to IEC 60559. The particular LIA-2 reference is page 3: 3. Normative References. Change the notations for intervals which do not include the end point: ]x,z] to (x,z] [x,z[ to [x,z) ]x,z[ to (x,z) based upon CRC Standard Mathematical Tables. The particular LIA-2 reference is page 4: 4.1 Symbols. Replace "I not equal to Z" (shows up in 5.1.1 for wrapI(x) and elsewhere) with "I is bounded". Replace "I equal to Z" with "I is unbounded". Consider changing conformance to allow some legacy languages such as FORTRAN to comply to LIA-1 but not LIA-2, but to at least pass through the LIA-1 conformant data types when dealing with LIA-2 level interchange. This will allow interoperation even when languages cannot be extended to conform to LIA-2. Specific pages: Page 3: 2 Conformity: Note 2: Remove: ", which in turn includes (explicitly or by reference) a binding for IEC 559 as well". Reason: Our understanding of LIA-1 is that it does not require conformance to IEC 559 (IEEE-754). Page 8: 4.2 Definitions: Change: The number of digits in the fraction of a floating point number to The number of base-r digits in the fraction f of a floating point number of the form 0.f * r**e. Page 9: Change subnormal to some other term as it conflicts with the usage in IEEE-854. Page 9: Move: "For some operations the exceptional value invalid is produced only by input values of -0, +INF, -INF, or sNaN. For these operations the signature does not contain invalid." from page 83 A.5.3.1 Specification format to page 9 5. Specifications for the numerical functions. It can be made into a Note. Page 9: 5.1 Additional basic integer operations: Rewrite the sentence: String formats for integer values usually do contain (signalling) NaNs, however, when that string format is regarded as an (non-ISO/IEC 10967-1) integer datatype. It makes no sense and we do not understand the intent, so do not have a suggested rewrite. Also, we have yet to seen an integer sNaN, so we disagree with the word "usually" here. Page 10: 5.1.2 Integer maximum and minimum operations: Either add definition for the case of max_seq: n == 0 and -INF is available or remove "and -INF is available". Either add definition for the case of min_seq: n == 0 and +INF is available or remove "and -INF is available". Page 10: 5.1.3 Integer positive difference (monus, diminish) operation: Should the note mention the case of x = +INF and y = +INF? Change "limited integer types" to "bounded integer types". Page 10: 5.1.4 Integer power and arithmetic shift operations: Change "invalid(1)" to 1. Aside: Based upon other parts of LIA-2, it appears that "(1)" is a continuation value (not a footnote). But, where is that convention defined? Add the case: = 1 if x = 1 Add the case: = +1 if x = -1 and y is even Add the case: = -1 if x = -1 and y is odd Page 12: 5.1.8 Greatest common divisor and least common multiple operations: For the invalid case, change invalid to invalid(0) and remove: and +INF is not available. Change Note 1: "would be incorrect, since the greatest common divisor for 0 and 0 is infinity" to "was considered but rejected". Reason: INF | 0 means INF * n = 0 for some n. But there is no n that satisfies the requirement. Hence, +INF is not the GCD of 0 and 0. Also, we believe that 0 <= GCD(x,y) <= min(abs(x),abs(y)). In: gcd_seqI ([x1 ; ...; xn]), remove and +INF is not available. Add a note to that entry: { 0 } = { x1 ; ...; xn } means all xi are 0. Page 14: 5.2.1 The rounding and floating point result helper functions: Change: "= 0 if x = 0" to "= x if x = 0". Reason: To do the correct action for -0 and IEEE-754. Add a note to that section: If denormF is false, the distinction between the ordering of rounding and underflow detection is not made. That is, a number x might be just under fminNF, so might round to fminNF in one implementation and be flushed to zero (before rounding) in another. Page 18: 5.2.5 Operation for remainder after division and round to integer (IEEE remainder): Add the missing space in "yis" in: "if x is a quiet NaN and yis not a signalling NaN". Page 19: 5.2.7 Support operations for extended floating point precision: add_lo: If x, y, and addF(x,y) are all in F then the specified result is fine. But, one or more of x, y, and addF(x,y) are not in F, then there are two viewpoints: add_lo(x,y) is always zero (and there are no exceptions), or add_lo(x,y) is the same as addF(x,y) with the same exceptions. Both viewpoints are acceptable. Whichever you adopt, the definitions need to be redone. For example, the "underflow(0)?" entry should be either "0" or "underflow(0)". And the entry "0?" should be either "0" or "floating_overflow(+/-INF)". The same idea applies to sub_lo, mul_lo, div_rest, and sqrt_rest. Page 20: Remove add3 as we see no need for it. Page 21: Remove add3_mid as we see no need for it. Page 22: Remove mul_add_midF as we see no need for it. It can be simulated with *, mul_lo, +, and add_lo. Page 23: 5.2.8 Exact summation operation: Change result in: = sNaN if x = +INF and y = -INF to be qNaN. Change result in: = sNaN if x = -INF and y = + INF to be qNaN. Page 25: 5.3.1.2 The trans result helper function: = underflow(nearestF(x)) clause has two problems: (nearestF (x) < 0 or x 0) seems wrong and we do not know what is should be. It also seems that if nearestF(x) == x, e.g., x is exactly representable as a denormal, there should not be an underflow. Page 26: 5.3.2 Hypotenuse operation: Change the specification so that hypot(+/-INF, qNaN) and hypot(qNaN, +/-INF) is +INF (not qNaN). Reason: if one of x or y is an infinity, then no matter what value the other argument has, the result is +INF. Pages 28-29: We disagree with many of the powerFF and powerFI subcases. We have complained before and been rejected, so we believe that it will do no good to give the detailed rewrites, but we can provide them if you would like them. Page 42: 5.3.6 Operations for radian trigonometrics and inverse radian trigonometrics: Change: "It [big_angle_r] shall have the following default value" to "It shall have a default value at least as large as". Reason: We know of implementations that use enough digits of pi for argument reduction to correctly compute the trig functions for all arguments. Page 48: arcF: remove the "?inval?" items. Page 48: arcF (we call it arctan2): We disagree with the +/-0, +/-0 subcases. We have complained before and been rejected, so we believe that it will do no good to give the detailed rewrites, but we can provide them if you would like them. Page 58: 5.3.7.11 Argument angular-unit arcus operation: Remove "?inval?" items. Pages 66-72: For all the 5.4.* functions: Add: invalid if x is a quiet NaN and quiet NaN is not available in the target type. For all the 5.4.* functions: There are several cases to consider for signaling NaNs. It the type is changed (int - float, or float - int), or if the precision is changed (I - I' or F - F'), that is, a conversion is done, then signaling NaNs shall raise invalid and produce a qNaN as a continuation value. But, if the type and precison are the same, then it is implementation defined if the copy operation leaves sNaN alone or raises invalid and produces a qNaN as a continuation value. Reason: IEEE-754 allows the implementor to pick if copying sNaNs raises invalid or not. IEEE-754 requires sNaNs to raise invalid on conversions. [MAJOR] For roundingF, floorF, ceilingF, change integer_overflow to integer_overflow or invalid (implementation defined). Reason: There are many hardware implementations of IEEE-754 that raise invalid for bad conversions from floating-point to integer. Page 68: 5.4.4 Floating point to floating point conversions: It appears that LIA-2 is missing functions to meet IEEE-754 for directed rounding of binary <-- decimal conversions, e.g., "input" and "output" of string formats. Each function for input or output is supposed to use the current rounding direction. This also applies to 5.4.5 and 5.4.6 functions. Page 69: 5.4.5 Floating point to fixed point conversions: Need to add a definition or reference to LID. Should "limited" be changed to "bounded"? Page 73: 5.5.2 Numerals for floating point types: Change statically to dynamically in: The rounding circumstance should be statically determined, if other than the normal is at all available. Check signalling versus signaling. Both are used in LIA-2 (in particular on page 74). Expand note 2 in clause 7 to include COBOL, which is still the most widely used programming language. In particular, please add the following: "function asin(x) in COBOL". Page 79: A.1.1 Specifications included in ISO/IEC 10967-2: Change "intened" to "intended". Page 82: A.5.2.7 Support operations for extended floating point precision: 3rd paragraph: Add a missing 'by' to: the high parts are calculated the corresponding floating point operations. Page 93: Annex C: Example bindings for specific languages: Remove: In turn, a complete binding for the ISO/IEC 10967-1 will include a binding for IEC 559. Page 99: C.2 Ada: Complete: Numerals for infinity... Page 99: C.3 BASIC: Complete: The BASIC datatype ???? corresponds to the LIA-1 datatype Boolean. Page 103: C.4 C and C++: Add the reference number for C++ to the first paragraph. Page 104: Change: divides(x, y) to y % x == 0. Page 104: Change: evenI(x) x % 2 = 0 to evenI(x) x % 2 == 0. Page 104: Change: min(x, y) to fmin(x, y). Page 104: Change: max(x, y) to fmax(x, y). Page 104: Change: ffloorf(x), ffloor(x), ffloorl(x) to floor(x). Page 104: Change: ceiling(x) to ceil(x). Page 104: Change: dim(x, y) to fdim(x,y). Page 104: Change: ????(x, y) to dprod(x,y). Page 104: Change: mul_add(x, y, z) to fma(x,y,z). Page 104: Change: sqrtf(x), sqrt(x), sqrtl(x) to sqrt(x). Page 105: Change: hypotenuse(x, y) to hypot(x,y). Page 105: Change: power(b, y) to pow(b,y). Page 105: Change: ln(x) to log(x). Page 105: Change: ln1p(x) to log1p(x). Page 105: Change: log(b, x) to logbase(b,x). Page 105: Change: log1p(b, x) to logbase1p(b,x). Page 107: Add to: convertI-I-(x): cast, e.g., (type of I-)x. Page 107: Change: rounding(y) to (INT)round(y). Page 107: Change: floor(y) to (INT)floor(y). Page 107: Change: ceil(y) to (INT)ceil(y). Page 107: Add to: cvtnearestF-D(y): sprintf(). Page 107: Add to: cvtnearestD-F(z): strtod(z,NULL). Page 107: Either remove or replace the .... in: C provides non-negative numerals ....... with for all its integer and floating point types. Page 112: C.6 Java: Remove long double and change three to two. Page 121: C.7 ISLisp and Common Lisp: Complete: The details are not repeated here, see .... Page 125: C.8 Modula 2: Complete: Modula-2 provides non-negative numerals ....... Page 129: C.9 Pascal and Extended Pascal: Complete: Pascal provides non-negative numerals ....... Page 131: Annex D Bibliography: Item [1]: Change 559 to 60559. Add at end: (previously designated IEC 559:1989). Page 132: Add to item [27]: A corrected tenth edition has been published by Dover Publications, New York. _______________________ end of USA comments ________________________ ________________________end of SC22 N2879 _________________________