From mpeacock@ANSI.org Mon Feb 14 21:41:06 2000 Received: from email1.ansi.org (mail.ansi.org [165.254.114.6]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id VAA29263 for ; Mon, 14 Feb 2000 21:41:04 +0100 (CET) (envelope-from mpeacock@ANSI.org) Received: by email1.ansi.org with Internet Mail Service (5.5.2232.9) id <1RJSHA3C>; Mon, 14 Feb 2000 15:39:41 -0500 Message-ID: <7C5DF9EFFBA9D11187E90020356797B201606609@email1.ansi.org> From: Marisa Peacock To: "'sc22info@dkuug.dk'" Cc: "'Keld Jørn Simonsen'" Subject: SC22 N3071- Summary of Voting on SC 22 N 3023, FCD Ballot for FCD 10967-2, Information Technology - Language Dependent Arithmetic - Part 2 : Elementary Numeric Functions (2nd FCD Ballot) Date: Mon, 14 Feb 2000 15:39:39 -0500 X-Mailer: Internet Mail Service (5.5.2232.9) ________________________ 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 N3071 TITLE: Summary of Voting on SC 22 N 3023, FCD Ballot for FCD 10967-2, Information Technology - Language Dependent Arithmetic - Part 2: Elementary Numeric Functions (2nd FCD Ballot) DATE ASSIGNED: 2000-02-14 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: JTC 1.22.33 STATUS: WG 11 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the FCD. ACTION IDENTIFIER: FYI to SC22 Member Bodies ACT to WG 11 DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: N3023 DISTRIBUTION FORM: Def ________ end of title page; beginning of overall summary ____________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N3023 Circulated by: JTC 1/SC22 Circulation Date: 1999-10-08 Closing Date: 2000-02-08 SUBJECT: FCD Ballot for FCD 10967-2: Information technology - Language Independent Arithmetic - Part 2: Elementary Numeric Functions (2nd CD Ballot) ----------------------------------------------------------------------- The following responses have been received on the subject of FCD approval: "P" Members supporting approval without comments 5 (Belgium, China, Finland, Netherlands, United Kingdom) "P" Members supporting approval with comments 1 (USA) "P" Members not supporting approval 2 (France, Japan) "P" Members abstaining: 3 (Austria, Denmark, Norway) "P" Members not voting: 10 (Brazil, Canada, Czech Republic, Egypt, Germany, Ireland, Romania, Russian, Federation, Slovenia, Ukraine) ---------------------------------------------------------------------- "O" Member Comments: 1 (Sweden) ----------------------------------------------------------------------- Secretariat Action: WG 11 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the FCD. ____ Beginning of National Body Comments _____________ FRANCE France votes NO with comments to the FCD 10967-2: Language Independent Arithmetic - Elementary Numeric Functions. The vote will be reversed if the following comments are satisfactorily resolved. EDITORIAL COMMENTS Comment 1. Final committee draft: whole document Category: Request for replacing 'C9x' with 'C99' (minor editorial) Rationale: The C9x project had successfully been completed, and the revised standard was published in 1999 by ISO. Proposed resolution: Change 'C9x' to 'C99'. As a consequence the reference [18] should be updated. Comment 2. Final committee draft: whole document Category: Request for consistency with LIA-1 about 'datatype' (minor editorial) Rationale: LAI-1 used the term 'data type' (iin two words) whereas the current draft is using 'datatype'. We feel that for the sake of consistency, LIA-2 should adhere to LIA-1 terminology. Proposed resolution: Change 'datatype' to 'datatype'. TECHNICAL COMMENTS Comment 3. Final committee draft subsection: C.5 Category: Request for improving C++ bindings (major technical) Comment 3.1 Rationale: The C++ programming language has its own preferred idioms (e.g. overloading, templates, iterators, ...) to express some constructs. We feel that it is strongly recommanded LIA-2 uses them. For example valarray is not the only possible way to form sequences in C++. One other popular way is 'C-like array' which can't have member function ('min()', 'max(), ...). C++ uses the 'iterator' concept to abstract algorithms over data strutures, which implies among other thing that requiring 'min()', 'max()', 'gcd()', 'lcd()', 'nmax()', 'nmin()' be member functions isn't likely to fit into the general iterator framework. Proposed resolution: o change 'xs.max()' to 'max(xs_start, xs_end_past_one)' o change 'xs.min()' to 'min(xs_start, xs_end_past_one)' o change 'xs.gcd()' to 'gcd(xs_start, xs_end_past_one)' o change 'xs.lcm()' to 'lcm(xs_start, xs_end_past_one)' o change 'xs.nmax()' to 'nmax(xs_start, xs_end_past_one)' o change 'xs.nmin()' to 'nmin(xs_start, xs_end_past_one)' These bindings were already suggested in our comments on the last draft. Comment 3.2 Rationale: We also feel that distinguishing between functions, having conceptually the same name but operating on values of different types, by prefix or suffix does not fit into the C++ approach to genericity. Instead, overloading should be used. Proposed resolution: o Change 'iremainder(x, y)' to 'remainder(x, y)' o Change 'poweri(b, z)' to 'power(b, z)' Comment 3.3 Rationale: C++ allows a template function to be overloaded on the return type. That feature is exactly what should be used to suggest a binding for mult_F'->F. The scheme is extensible. Proposed resolution: Change 'dprod(x, y)' to 'product(x, y)' Comment 3.4 Rationale: C++ defines a standard template class 'numeric_limits' to provide the user with information about numerical types. We strongly feel that the non-member functions enabling access to the parameters for operations approximating real valued transcendtal functions should be defined members of the template class 'numeric_limits'. Proposed resolution: o Change 'err_hypothenuse()' to 'numeric_limits::err_hypothenuse()' o Change 'err_exp()' to 'numeric_limits::err_exp()' o Change 'err_power()' to 'numeric_limits::err_power()' o Change 'err_sinh()' to 'numeric_limits::err_sinh()' o Change 'err_tanh()' to 'numeric_limits::err_tanh()' o Change 'big_radian_angle() to 'numeric_limits::big_radian_angle()' o Change 'err_sin()' to 'numeric_limits::err_sin()' o Change 'err_tan()' to 'numeric_limits::err_tan()' o Change 'smallest_angle_unit to 'numeric_limits::smallest_angle_unit()' o Change 'big_angle()' to 'numeric_limits::big_angle()' o Change 'err_sin_cycle()' to 'numeric_limits::err_sin_cycle()' o Change 'err_tan_cycle()' to 'numeric_limits::err_tan_cycle()' o Change 'err_convert()' to 'numeric_limits::err_convert()' o Change 'err_convert_string()' to numeric_limits::err_convert_string()' Comment 3.5 Rationale: As far as casts are concerned, C++ recommands use the 'new style casts' syntax. Especially in the case of numerical conversion, 'static_cast' should be used. Proposed resolution: o Change '(INT2)x' to 'static_cast(x)' o Change '(INT)nearbyint(y)' to 'static_cast(nearbyint(y))' o Change '(INT)floor(y)' to 'static_cast(floor(y))' o Change '(INT)ceil(y)' to 'static_cast(ceil(y))' o Change '(FLT)x' to 'static_cast(x)' o Change '(FLT2)y' to 'static_cast(y)' Comment 3.6 Rationale: As to how to convert values of arithmetic types to string type (or vice-versa), C++ has a powerful system of streams: these streams are the recommanded means for I/O issues. Proposed resolution: Replace use of 'sscanf', 'fscanf', 'fprintf', 'sprintf' with reference to 'locale and facets' (paragraph 22.2.2 of ISO/IEC:14882:1998). Comment 3.7 Rationale: C++ already defines binding for '+oo', 'qNaN', 'sNaN' as the return values of the functions numeric_limits::infinity(), numeric_limits::quiet_NaN(), numeric_limits::signaling_NaN(). Proposed resolution: o Replace 'INFINITY' with 'numeric_limits::infinity()' o Replace 'NAN' with 'numeric_limits::quiet_NaN()' o Replace 'SIGNAN' with 'numeric_limits::signaling_NaN()'. JAPAN ISO/IEC 10967-2, Information technology - Language independent arithmetic - Part 2: Elementary numerical functions Japan disapproves the draft for reasons shown below. --------------------------------------------------------------------------- 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. ---------------for the core------------------------------------------------ Forward, 1st paragraph, last line: "organisations" should be "organizations". 1.1 Inclusions, 1st paragraph, 1st line: Remove "of" after "Part 1". 4.1.4 Datatypes and exceptional valuses: The symbols F and I should be introduced before their usage such as boundedI and eminF. 4.1.4, p.6, after NOTES, 2nd line: "tree" should be "three". 5.1.2 Integer maximum and minimum: The return values for empty list should be: max_seqI([]) = invalid(-Infinity), and min_seqI([]) = invalid(+Infinity), not as poles. In 4.2, pole is defined and reserved for continuous functions. Those functions max_seqI and min_seqI are not continuous on length of their argument lists in usual sense. (Of course, you may claim they are continuous functions under interpretation of cpo's.) 5.1.6 Divisibility tests, NOTES 1: We believe that dividesI(0,0) = true, since dividesI(x,y) = x|y and x|y should be defined as "for some integer m, y= m x", and clearly we have 0= m 0 for any integer m. 5.1.8 Greatest common divisor: We believe that gcdI(0,0)=invalid(+Infinity), since notion of "continuous function" does not apply for this function and, thus, "pole" seems inadequate. 5.1.8 Greatest common divisor: A NOTE on the empty list case should be added in the definition of gcd_seqI, as in lcm_seqI. 5.2.1 The rounding and floating point result helper function, 2nd para.: We don't see the reason why resultF(x, upF)=overflow(-fmaxF) for the case upF(x) < -fmaxF. "upF(x) < - fmaxF" means that x is not greater than y such that nearestF(y) < -fmaxF and thus resultF(x,upF) cannot be greater than resultF(y,nearestF)=overflow(-Infinity). Any persuasive reason should be given, or change it to resultF(x, upF)=overflow(-Infinity). Similar discussion holds for resultF(x, downF)=overflow(fmaxF) for the case downF(x)>fmaxF. 5.2.2 Floating point maximum and minimum: The first two lines of the definition in max_seqF([x1, ?, x2]) should be unified into: max_seqF([x1, ..., xn]) = invalid(-Infinity) if n=0. max_seqF is not continuous on length of its argument list, and thus the notion of pole doesn't apply for this case. (see the discussion for max_seqI.) The case when the implementation doesn't have "Infinity" should be left open as "implementation defined" as described in the last paragraph of 4.1.4. (For example, see 5.3.6.6. There is only a description: powerF(0,y)=pole(+Infinity) if y<0 and it leaves open the case when the implementation doesn't have "Infinity". And it is far better to put a general recommendation or requirement rather than to put in individual case the description saying that the implementation should substitute fmin_N for "Infinity" if it doesn't have "Infintiy".) Also the first two lines of the definition in min_seqF([x1,...,xn]) should be unified into: min_seqF([x1,...,xn]) = invalid(Infinity) if n=0. 5.2.4 Round, floor, and ceiling: Commas between "Infinity" and "}" should be deleted. (roundingF, floorF, and ceilingF) 5.2.4 Round, floor, and ceiling: We are afraid that the value of rounding_restF(x) might be resultF(x-round(x),rnd_F) rather than simply x-round(x), since those values for floor_restF and ceiling_restF are resultF-ed. 5.2.6 Square root: We don't find any clear reason for sqrtF(-0)= -0. sqrtF(x) is undefined for all negative value x, and -0 is a negative, or at least the limit of negative values, thus ... 5.2.7 Supporting operations, NOTE1, 2nd line: "returns" should be "return". 5.3.2 Sign requirements, 1st paragraph, 1st and 3rd lines: "are shall" should be "shall". 5.3.6.1 powerI: Add comma between "infinity" and -0. Remove empty lines above and below this line. 5.3.6.6 PowerF: It is defined now that powerF(0,0) = result_NaN2_F(0,0), and by definition, = invalid(qNaN), whereas powerFI(0,0)=1 and powerI(0,0)=invalid(1). Are they consistent? Rationale should be given for their treatment. 5.3.6.7 power1pm1: It should be power1pm1F*(x,1)=x . 5.3.6.8 Natural logarithm: All helper functions should be defined as functions on R rather than on F. In the draft, some helper functions such as lnF* are define as R->R whereas the others are defined as F->R, because, we guess, those specific helper functions have requirements on the real values such as "pi" and e that cannot be members of F. We cannot find out any benefit to distinguish such differences. We prefer to simple style. 5.3.6.12 Argument base logarithm: It should be logbaseF(1,y) = invalid(qNaN) for any y, since for any fixed y0, lim(x->1) logbaseF(x,y0) is undefined because the limit depends on the approaching direction. 5.3.6.12 Argument base logarithm: Remove two empty lines in the definition of logbaseF(x,y). 5.3.7.8 Inverse hyperbolic cosine: For each helper function its domain should be specified clearly if it is not required to be total on R (though some are currently defined on F; we propose to change them to R.). For example, arccoshF*(x) should be defined "if |x|>=1", and arctanhF*(x) should be defined "if |x|<1". 5.3.7.12 Inverse hyperbolic cosecant: We don't find any reason why such a specific relation as arccschF*(1)=arcsinhF*(1) is given in the specification. Moreover we don't see whether it is a remark or a requirement since the current description simply says as "Relationship to the arcsinhF* approximation helper funcion". If it is a remark, it should be placed as a "NOTE" or in the annex. 5.3.9.1 Radian angle normalisation, 2nd paragraph, 3rd line: "x<=big_angle_rF" should be "|x|<=big_angle_rF". 5.3.9.1 Radian angle normalisation: The signature of axis_radF should be F -> ((I x I) x F) ..., since the first part of the returned value is one of (1,0), (0,1), (-1,0) and (0,-1) and this fact could be clearly indicated by "(I x I)" rather than "(F x F)". 5.3.9.3 Radian cosine: We don't find reasons why there is no requirement on cosF*(pi/2) = cosF*(-pi/2) = 0 while there are requirements on the cases when cosF*(x) has the values 1, -1, 1/2 and -1/2. 5.3.9.4 Radian tangent: "n*2*pi" should be replaced with "n*pi", since the period for tan(x) is pi rather than 2*pi. 5.3.9.5 Radian cotangent: "n*2*pi" should be replaced with "n*pi", since the period for cot(x) is pi rather than 2*pi. 5.3.9.8 Radian cosine with sine: Some functions such as cossinF and cossinuF (5.3.10.8) return a pair of results of other functions. There should be general definition on how to handle the result when one or both of the other functions return notification or special values, especially on how to define the continuation value with those ones returned from the other functions. 5.3.9.10 Radian arc cosine: Is it not necessary to require arccosF*(1) = 0 ? 5.3.9.10 Radian arc cosine: The expression "-1<=x<=1" should be rewritten as "|x|<=1". 5.3.9.15 Radian angle from Cartesian co-ordinates: It is defined now that arcF(0,0)=0 whereas in the previous draft it was arcF(0,0)=invalid. Rationale should be given somewhere. 5.3.10 Operations for trigonometrics with given angular unit: The angular unit should be limited to positive value. No one really wants to use a negative unit, and negative units make the current description unduely complicated. 5.3.10, NOTE2: Put space between "is," and "min_angular_unitF". 5.3.10, last paragraph, last line: A continuation value (in parentheses) should follow the word "invalid". 5.3.10.1 Argument angular-unit angle normalization: The signature of axis_cycleF should be F -> ((I x I) x (F...))..., since the first part of the returned value is one of (1,0), (0,1), (-1,0) and (0,-1) and this fact could be clearly indicated by "(I x I)" rather than "(F x F)". 5.3.10.12 arccotu, Range limitation: Range limitation for arccotuF#(u,x) should be revised. Though the expression given in the draft well limits the range in the sense that there are no values u and x which produce a result out of it, the expression is too loose (giving just the doubled range) for a specific value u. Example of revision: arccotuF#(u,x) = max{0, min{arccotuF*(u,x), down(u/2)}} if u>0 = min{max{arccotuF*(u,x), upF(u/2)}, 0} if u<0 5.3.10.13, definition of arcsecuF(u,x): "(x<=-1 or x>=1)" should be rewritten as "|x|>=1". 5.3.10.14, definition of arccscuF(u,x): "(x>=1 or x<=-1)" should be rewritten as "|x|>=1". (By the way, why does it differ from the expression given in arcsecuF?) 5.3.11.1 rad_to_cycle: The second argument of rad_to_cycle should be "u" instead of "v", just as in the other arbitrary angular unit functions. 5.3.11.1 rad_to_cycle, 1st paragraph, last line: The maximum error of rad_to_cycleF*(x,u) should be max_error_sinuF rather than max_error_sinF. Note that rad_to_cycle and cycle_to_rad are reciprocal to each other, and thus one has the maximum error related to sin (cycle_to_rad), the other should have the error related to sinu. --------------------for annexes ----------------------------------------- B.4.1.2, 3rd line: The word "programme" looks strange. We prefer "program". B.4.1.2, 5th line: We think that the word "whether" is inadequate here. It is used as the first word of an adverb phrase. B.4.1.4, 6th paragraph, 3rd line: There should be a grammatical error in the sentence "... continuation value to cause ...". Perhaps, the word "to" before "cause" should be removed. B.5.1.2, 5th line: There should be a grammatical error in the sentence "... be possible handle at ...". Perhaps, "to" should be inserted before "handle". B.5.1.3, 1st line: The direction of the quotation mark before "positive difference" is not correct. The mark before "monus" should also be used here. B.5.1.7, 1st line: We cannot understand why "47" appears here. Is it the representation of an apostrophe? B.5.1.7, 3rd paragraph, 1st line: We cannot understand what the phrase "... does so for too many arguments, ..." means. The number of arguments of this function is fixed. B.5.1.8, 1st line: One of two consecutive "a"s should be removed. B.5.1.8, 4th paragraph, 2nd line: We think that the use of the noun "relative prime" is not common in mathematics. We think that the notion should be phrased as an adjective. Thus we prefer to change "relative primes" to "relatively prime". B.5.2, 4th paragraph, 1st line: There is no subject corresponding to the verb "summarise". B.5.2, 6th paragraph, 8th line: The word "thought" should be changed to "though". B.5.2.2, 2nd paragraph, 1st line: The word "one" looks strange in this context. B.5.2.5, 2nd paragraph, 2nd line: We think that the word "nominator" should be changed to "numerator". The word "looses" should be changed to "loses". B.5.3.6, 2nd paragraph of page 80, 4th line: We do not know the word "suppied". Is it a misspelling of "supplied"? B.5.3.11, 3rd line: The word "looses" should be changed to "loses". B.5.4, 5th paragraph, 1st line: The phrase "greater that" should be changed to "greater than". C.2, Ada binding: The reference to ISO/IEC 11430 is not appropriate. It is provided as a supplement to the old Ada standard (8652:1987). The contents of this standard is included in the new Ada standard (8652:1995), and therefore 11430 is obsolete. It will soon be withdrawn. The function name "Rem" is not possible. The word "rem" is a reserved word in Ada. The type description "array of INT" is not complete. Every Ada array type should have its index type specified. If such generic array types, regardless of their index types are necessary, the "generic" mechanism of Ada should be used. The same comment also applies to Pascal (Pascal does not have generic mechanism). Functions returning max_error parameters are defined to have a parameter to differentiate among the floating point types. This is not consistent with the usual Ada style. In the usual Ada coding style, such functions should be defined as "attributes" with the type name as the prefix. We feel strange finding that the parameter name "Cycle" is given to the functions "arctanu" and "arccosu". Yes, the parameter name is necessary to distinguish these functions from the function "arc" with two parameters. However, there is no reason not to give parameter names to other functions. It would be more consistent to give names to all parameters of all functions. This is the usual style of Ada. After the definition of "mul" function, the variable "z" is defined to have the type FLT, but this variable does not appear in the block. The same comment also applies to Basic, C, C++, Fortran, Haskell, Java, Common Lisp, ISLisp, Modula-2, Pascal, PL/I and SML. After the definition of "cycle_to_cycle", the phrase "z is an expressions" is grammatically incorrect. The "s" should be removed. The same comment also applies to C++, Fortran, Haskell, Java, Common Lisp, ISLisp, Modula-2, Pascal, PL/I and SML. After the definition of "convert" functions, the generic type "INT2" is defined but "FLT2" is not. It is referred to in the definition of the "F->F' conversion" function, and thus should be defined. The same comment also applies to C, C++, Java and Modula-2. C.3, Basic binding: Several functions are not given in the binding. For example, we could not find the definitions of "powerFI", "mul", "axis_rad" and "axis_cycle" functions. Is this intentional? For the function "mul", the same comment also applies to C++, Fortran, Java, Common Lisp, ISLisp, Modula-2, Pascal, PL/I and SML. Your writing style seems to insert a space after comma for the functions, defined in the programming language, having more than one parameter. This style is often violated. The same comment also applies to many other languages. C.4, C binding: The new version of 9899 has been published. The reference to the standard should be updated. Moreover, references to "C9X" as a preliminary draft are not appropriate. The word "C9X" which appears in many places of this FCD should finally disappear. There are two definitions of the "divides" function. Is this intentional? How can we choose one of these? The same comment also applies to C++. The definition of the mark "*" says "needs one name per integer datatype". However, there is no suggestion how these names should be constructed. If implementers choose different names, there will be portability problems. We understand that C does not have "type generic macros" mechanism. The implementer of the numeric library cannot write these macros in C. After the definition of "convert" functions, the variable "z" is defined to have the type "FXD". However this variable does not appear in the block. The type "FXD" is defined, but it does not appear in the block. The same comments also apply to C++, Fortran, Haskell, Java, Common Lisp, ISLisp, Pascal, PL/I and SML. C.5, C++ binding: The definition of the "divides" function (second one) is incorrect. The subexpression "y != 0" should be changed to "x != 0". The comment "(unclear)" appears in many functions. We think that this is not acceptable as a description in a standard. After the definition of "cycle_to_cycle", the phrase "... conversions in C++ are can be explicit ..." is grammatically incorrect. The word "are" should be removed. The same comment also applies to Common Lisp, ISLisp, Modula-2, Pascal and PL/I. C.6, Fortran binding: The type "FLT" is referred to, but is not defined. The notation (*) appears in many functions (for example, "rounding"), but the meaning of the notation is not explained. After the definition of "max_error" functions, the variable "b" is defined but does not appear in the block. The same comment also applies to Haskell, Common Lisp and ISLisp. Several functions are not given in the binding. For example, we could not find the definitions of "axis_rad" and "axis_cycle" functions. The phrase "The Kind of the a numeral ..." is grammatically incorrect. The word "the" should be removed. C.7, Haskell binding: The phrase "Haskell provides ... in base is 10" is grammatically incorrect. The word "is" before "10" should be removed. The same comment also applies to ISLisp. C.8, Java binding: The types "INT" and "FLT" are referred to, but are not defined. The same comment also applies to Common Lisp, ISLisp, Modula-2, Pascal and PL/I. The names of the parameters of the function "max_err_powerF" is "b" and "x". We cannot understand why the name "b" is chosen here. C.9, Common Lisp binding: After the definition of the "sqrt_rest" function, a grammatically incorrect phrase "a data objects" appears. The "s" should be removed. After the definition of the "convert" functions, a misspelled word "Convertion" appears. It should be changed to "Conversion". In the last paragraph of the binding, a grammatically incorrect phrase "... operations returns a complex ..." appears. The "s" at the end of "returns" should be removed. C.10, ISLisp binding: In the first paragraph of page 128, "a ISLisp object" should be changed to "an ISLisp object". After the definition of the "sqrt_rest" function, "an data objects" should be changed to "a data object". C.11, Modula-2 binding: After the definition of the "cycle_to_cycle" function, "... conversions in C" is referred to. "C" should be changed to "Modula-2". After the definition of "sNaN", "an Modula-2 exception" should be changed to "a Modula-2 exception". The line containing "WHOLE-ZERO-..." is too long. The question mark in "(for pole, not overflow?)" is not adequate. C.12, Pascal binding: After the definition of "convert" functions, "FDIS 9899" which is the standard of C appears. The clause numbers "xxxxxx" and "yyyyy" should be changed to concrete numbers. C.14, SML binding: In the definition of the "powerFI" and "pow" functions, the parameter names "x" and "y" are referred to. They are different from the parameter given in the specification. After the definition of "convert" functions, the type "INT2" is defined which does not appear in the block. SWEDEN Clause 4.1.4, add add before "The following symbols are defined in > Part~1": > < Let $I$ be the non-special value set for an integer datatype conforming > to > < Part~1. Let $F$ be the non-special value set for a floating point > datatype > < conforming to Part~1. > > > Clause 4.1.4, note 3, replace "justly allow avoiding" with "be able to > avoid" > (better English). > > > Clause 4.2, def. of cont. val.: > replace "value in $F$" with "(in the datatype representable) value in > $\RR$" > (slight generalisation, suitable for the definitions section). > > Clause 4.2, def. of monotonic approximaiton: > Replace "operation $op_F: ... \times F \times ... \rightarrow F$" with > "floating point operation $op_F: ... \times F \times ... \rightarrow F$, > for a floating point datatype with non-special value set $F$" (more > explicit). > > > Clause 4.2, def. of monotonic approximaiton: add "$a < b$,". > > > > On power_FI: Generalise: > > $power_{\!FI}^*(1,y) = 1 $ \>\>if $y \in I$\\ > > to > < $power_{\!FI}^*(x,y) = x^y $ \>\>if $y \in I$ > and $x \in \ZZ\cap F$ and ($y>0$ or $|x|=1$)\\ > > > On power_FI: Add: > < Relationship to other $power_{\!FI'}^*$ helper functions for > $power_{\!FI'}$ operations in the same library: > < \begin{example}\atab > < $power_{\!FI}^*(x,y) = power_{\!FI'}^*(x,y)$ \>\>if $x\in F$ > and $y \in I\cap I'$ > < \end{example} > > On power_I: change "since the exact result then is not in $\ZZ$" to > "(unless $|x|=1$) since the exact result then is not in $\ZZ$" > > On power1pm1: change "greater than $-1$" to "greater than or equal to > $-1$" > > On power1pm1: Add: > < $\mathit{power1pm1}_{\!F}^*(x, y) = (1+x)^y-1 $ \>\>if > $x,y \in F\cap\ZZ$ and $x\geq-1$ and $y > 0$\\ > > > On power_F: Change > > Relationship to the $power_{\!F}^*$ approximation helper function: > to > < Relationship to the $power_{\!F}^*$ approximation helper function > < for a $power_{\!F}$ operation in the same library: > > > > On arccot_F: change the note > > \begin{notes} > > $arccot_F(x) \approx arc_F(x,1)$. > > \next > > There is no ``jump'' at zero for $arccot_F$. > > \end{notes} > to > < \begin{note} > < $arccot_F(x) \approx arc_F(x,1)$ (the $arc_F$ operation is specified > below). > < \end{note} > > On arcctg, add in the note: > < Due to the range limitation, $arcctg_F(0)$ need not equal $arccot_F(0)$. > > > > > About big angle parameter for angualar unit parameter operations: change > > value greater than or equal to $1$ and such that $\ulp_F(big\_angle_F) > \leq 1/2000$. > to > < value greater than or equal to $1$ and such that > $\ulp_F(big\_angle\_u_F) \leq 1/2000$. > > and change > > In order to allow $\ulp_F(big\_angle_F) \leq 1/2000$, $p_F \geq > 2+\log_{r_F}(1000)$ should hold. > to > < In order to allow $\ulp_F(big\_angle\_u_F) \leq 1/2000$, $p_F \geq > 2+\log_{r_F}(1000)$ should hold. > > > On arcctg_F: add notes: > < \begin{notes} > < $arcctgu_F(neg_F(u,x)) = neg_F(arcctgu_F(u,x))$. > < \next > < Due to the range limitation, $arcctg_F(u,0)$ need not equal > $arccot_F(u,0)$. > < \end{notes} > > > > > Change the title: > > \subsection{Conversion operations} > to > < \subsection{Operations for conversion between numeric datatypes} > > > > > > On notification handling: change > > \item When ``recording of indicators'' is the method of notification, > the > > datatype used to represent $Ind$, the method for denoting the values of > > $Ind$ (the association of these values with the subsets of $E$ must be > > clear), and the notation for invoking each of the ``indicator'' > > operations. (See 6.1.2 of Part~1.) > > In interpreting 6.1.2 of Part~1, the set of indicators $E$ > to > < \item When ``recording of indicators'' is the method of notification, > < the datatype used to represent $Ind$ (see clause 6.1.2 of Part~1), > < the method for denoting the values of $Ind$, > < and the notation for invoking each of the ``indicator'' operations. > < $E$ is the set of notification indicators. > < The association of values in $Ind$ with subsets of $E$ must be clear. > < In interpreting clause 6.1.2 of Part~1, the set of indicators $E$ > > Partial conformity annex: change > > according to the normative text > to > < according to the main normative text > > > On clause A.4.2: Add: > < Note also the LIA distinction between denormal and subnormal. > < Subnormal include zero values, while denormal does not. > > > Rationale: change > > A report (\cite{soren}) issued by the ANSI X3J11 committee discusses > possible > to > < The report {\em Floating-Point C Extensions}\cite{fpce}, > < issued by the ANSI X3J11 committee, discusses possible UNITED STATES USA comments: Key: ---- USA comment number: --- 001 through 056 Clause/subclause #, WG11 N462 page # affected: --- C.sub &c, 000 through 154 Comment Category: --- M(major technical), m(minor technical), E(major editorial), e(minor editorial), or Q(question - clarification desired) Title: --- one-line summary Rationale: --- original description of the problem Proposed change: --- original --------------------------------------------------------------- Comments: --------------------------------------------------------------- Comment number: --- USA-001 Clause/subclause, page #: --- 1.2(g), 001 Category: --- e Title: --- excess "of" Rationale: --- meaningless use of "of" on first line Proposed change: --- remove "of" --------------------------------------------------------------- Comment number: --- USA-002 Clause/subclause, page #: --- 1.2(g), 002 Category: --- e Title: --- "spcification" Rationale: --- misspelled; reads better if plural Proposed change: --- replace "spcification" by "specifications" --------------------------------------------------------------- Comment number: --- USA-003 Clause/subclause, page #: --- 2 paragraph 4 , 003 paragraph 3 Category: --- e Title: --- singular specification needed Rationale: --- In 2nd sentence "In the case of ...", a singular "specification" is needed, both to convey the meeting and to satisfy rules of grammar. Proposed change: --- replace "specifications .. takes" by "specification .. takes" --------------------------------------------------------------- Comment number: --- USA-004 Clause/subclause, page #: --- 2 paragraph 5 , 003 paragraph 4 Category: --- e Title: --- comma needed Rationale: --- a comma between "operations" and "independently" is needed to improve readability. Proposed change: --- replace "... operations independently ..." by "... operations, independently ..." --------------------------------------------------------------- Comment number: --- USA-005 Clause/subclause, page #: --- 4.1.1, 004 Category: --- e Title: --- define before use Rationale: --- "F" is used in Note 2 in 4.1.3 before it is defined Proposed change: --- Move the definition of I (in 5.1) and F (in 5.2) here, or provide forward references in subclause 4.1.3. --------------------------------------------------------------- Comment number: --- USA-006 Clause/subclause, page #: --- 4.1.4 note 3, 006 Category: --- e Title: --- Unnecessary value judgment Rationale: --- 'justly allow avoiding' needs to be changed. One suggestion is: 2) in order to avoid an underflow notification ... Proposed change: --- delete "justly" --------------------------------------------------------------- Comment number: --- USA-007 Clause/subclause, page #: --- 4.1.4 paragraph after note 4, 006 Category: --- e Title: --- Misspelled "three" Rationale: --- spelled as "tree" Proposed change: --- change "tree" to "three" --------------------------------------------------------------- Comment number: --- USA-008 Clause/subclause, page #: --- 4.2 "monotonic approximation", 007 Category: --- m Title: --- relationship of a to b Rationale: --- In the definition of a and b, it is assumed that a> operators. (use of C operators is acceptable and does have the advantage of more compactly specifying non-default format codes.) Proposed change: --- use << and >> operators as the examples for convert bindings for C++ --------------------------------------------------------------- Comment number: --- USA-051 Clause/subclause, page #: --- C.7, 117 Category: --- e Title: --- spurious characters Rationale: --- meaningless characters need deleting Proposed change: --- In the last section of tables for Haskell, remove the (apparently) spurious sequences of "." characters preceding the "*"s. --------------------------------------------------------------- Comment number: --- USA-052 Clause/subclause, page #: --- C.8, 120 Category: --- Q Title: --- overloading? Rationale: --- both lnF(x) and logbaseF(b,x) are mapped to the Java function "log()". Does Java support function name overloading in this way? Proposed change: --- Verify that Java supports overloading in this manner, to allow the use of "log()" for the logbaseF(b,x) case, or change the spelling for the suggested representation for logbaseF(b,x). --------------------------------------------------------------- Comment number: --- USA-053 Clause/subclause, page #: --- C.10 arcsinuF binding, 131 Category: --- e Title: --- missing ")" Rationale: --- simple omission Proposed change: --- Supply ")" (4 places) --------------------------------------------------------------- Comment number: --- USA-054 Originator comment #: J11FT-54 Clause/subclause, page #: --- C.11 & C.12 discussions prior to the convert tables, 135 & 139 Category: --- e Title: --- cut/paste errors Rationale: --- fix spurious references to C in Modula & Pascal subclauses Proposed change: --- Change the references to C in the Modula and Pascal sections respectively and fix to reflect the appropriate languages --------------------------------------------------------------- Comment number: --- USA-055 Clause/subclause, page #: --- C.12 4th paragraph from last, 140 Category: --- e Title: --- missing clause specifications Rationale: --- placeholders need filling-in Proposed change: --- Replace references to clauses xxxxxx and yyyyy with the correct clause numbers --------------------------------------------------------------- Comment number: --- USA-056 Clause/subclause, page #: --- D [20], 152 Category: --- e Title: --- spurious date Rationale: --- "Currently under revision (1998)" I don't know what that "1998" is, but I can't believe that it is anything that is current or correct. (There is no real clue at the beginning of Annex D to explain what it is supposed to mean.) Proposed change: --- remove the "(1998)" Marisa Peacock ANSI 11 West 42nd Street New York, NY 10036 Telephone: (212) 642-4976 Fax: (212) 840-2298 Email: mpeacock@ansi.org