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)

From: Marisa Peacock <[email-masked]>
Date: Mon, 14 Feb 2000 15:39:39 -0500

________________________ 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<FLT>(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<FLT>()' to
'numeric_limits<FLT>::err_hypothenuse()'

o Change 'err_exp<FLT>()' to 'numeric_limits<FLT>::err_exp()'

o Change 'err_power<FLT>()' to 'numeric_limits<FLT>::err_power()'

o Change 'err_sinh<FLT>()' to 'numeric_limits<FLT>::err_sinh()'

o Change 'err_tanh<FLT>()' to 'numeric_limits<FLT>::err_tanh()'

o Change 'big_radian_angle<FLT>() to
'numeric_limits<FLT>::big_radian_angle()'

o Change 'err_sin<FLT>()' to 'numeric_limits<FLT>::err_sin()'

o Change 'err_tan<FLT>()' to 'numeric_limits<FLT>::err_tan()'

o Change 'smallest_angle_unit<FLT> to 
    'numeric_limits<FLT>::smallest_angle_unit()'

o Change 'big_angle<FLT>()' to 'numeric_limits<FLT>::big_angle()'

o Change 'err_sin_cycle<FLT>()' to 'numeric_limits<FLT>::err_sin_cycle()'

o Change 'err_tan_cycle<FLT>()' to 'numeric_limits<FLT>::err_tan_cycle()'

o Change 'err_convert<FLT>()' to 'numeric_limits<FLT>::err_convert()'

o Change 'err_convert_string<FLT>()' to 
   numeric_limits<FLT>::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<INT2>(x)'

o Change '(INT)nearbyint(y)' to 'static_cast<INT>(nearbyint(y))'

o Change '(INT)floor(y)' to 'static_cast<INT>(floor(y))'

o Change '(INT)ceil(y)' to 'static_cast<INT>(ceil(y))'

o Change '(FLT)x' to 'static_cast<FLT>(x)'

o Change '(FLT2)y' to 'static_cast<FLT2>(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<FLT>::infinity(),
numeric_limits<FLT>::quiet_NaN(), numeric_limits<FLT>::signaling_NaN().

Proposed resolution:

o Replace 'INFINITY' with 'numeric_limits<FLT>::infinity()'

o Replace 'NAN' with 'numeric_limits<FLT>::quiet_NaN()'

o Replace 'SIGNAN' with 'numeric_limits<FLT>::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<b (because
of the English meaning of non-decreasing and non-increasing)
Proposed change: --- after "and b (element of) F" add ", a<b"

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

Comment number: --- USA-009
Clause/subclause, page #: --- 4.2 "monotonic non-decreasing" etc., 007-008
Category: ---  e
Title: --- duplicate term definitions
Rationale: --- unnecessary duplication
Proposed change: --- Remove one of the duplicate definitions of monotonic
non-decreasing and monotonic non-increasing

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

Comment number: --- USA-010
Clause/subclause, page #: --- 4.2 "subnormal", 009
Category: ---  e
Title: --- inter-standard inconsistency
Rationale: --- LIA-2 vs (IEEE-854 and C9x) use inconsistent definitions for
the term "subnormal number". IEEE 854 and C9x do not include 0 and -0 as
possible values of "subnormal" quantities.
Proposed change: --- Choose a different term to represent the concept of the
union of denormalized numbers with 0 and -0 (it may be possible to finesse
this issue by rewording the (few) places where this term is used in the body
of LIA-2).

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

Comment number: --- USA-011
Clause/subclause, page #: --- 5.2.1 paragraph 1, 014
Category: ---  e
Title: --- provide friendly reference
Rationale: --- readers might not remember where to look for definition of F*
Proposed change: --- Consider adding after 'F*' as a note: "F* is defined in
LIA-1. It is the 'unbounded extension of F'".

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

Comment number: --- USA-012
Clause/subclause, page #: --- 5.2.1 result_NaN3F helper function, 015
Category: ---  e
Title: --- poor grammar
Rationale: --- "not .. neither .." is not idiomatic English
Proposed change: --- Change "not" to "neither" (three places)

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

Comment number: --- USA-013
Clause/subclause, page #: --- 5.3.2 paragraph 1, 021
Category: ---  e
Title: --- "are shall"
Rationale: --- poor grammar
Proposed change: --- change "are shall" to "shall" in two places

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

Comment number: --- USA-014
Clause/subclause, page #: --- 5.3.6.6-7, 026-027 
Category: ---  e
Title: --- function ordering
Rationale: --- grouping "power*" functions makes them easier to find
Proposed change: --- move them after 5.3.6.1, also make corresponding change
in Annex B (purely personal preference, based on naming conventions of
helper functions. This change separates the "Exponentiation of" titles, so
there is no perfect ordering).

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

Comment number: --- USA-015
Clause/subclause, page #: --- 5.3.6.7 Further requirements..., 027
Category: ---  m
Title: --- incorrect requirement
Rationale: --- The requirement that power1pm1*F(x,1) is equal to "1 + x" is
incorrect
Proposed change: --- It should be equal to "x"

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

Comment number: --- USA-016
Clause/subclause, page #: --- 5.3.9.10 paragraph 2, 041
Category: ---  m
Title: --- additional "Further" requirement
Rationale: --- improves interfunctional consistency
Proposed change: --- Add arccos*F(-x)=pi-arccos*F(x)

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

Comment number: --- USA-017
Clause/subclause, page #: --- 5.3.9.9-5.3.9.15 Range limitation sections,
041-044
Category: ---  e
Title: --- noun needed
Rationale: --- title insufficiently descriptive
Proposed change: --- "Range limitation" is an adjectival phrase - it needs a
noun to state the category that the "arc...#()" functions belong to. Change
'Range limitation' to 'Range limitation helper function' everywhere.

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

Comment number: --- USA-018
Clause/subclause, page #: --- 5.3.9.13 paragraph 2, 043
Category: ---  m
Title: --- additional "Further" requirement
Rationale: --- improves interfunctional consistency
Proposed change: --- Add arcsec*F(-x)=pi-arcsec*F(x)

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

Comment number: --- USA-019
Clause/subclause, page #: --- 5.3.9.15, 044-045
Category: ---  e
Title: --- define before use
Rationale: --- 5.3.9.11 Note 1 refers to arcF, not yet defined
Proposed change: --- Move 5.3.9.15 to before 5.3.9.9 (alternate: give a
forward reference in the Note)

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

Comment number: --- USA-020
Clause/subclause, page #: --- 5.3.10 last paragraph, 045
Category: ---  m
Title: --- error ranges too large
Rationale: --- Error ranges specified for max_error_sinuF(u) and
max_error_tanuF(u) have upper bounds of 2 and 4 respectively. These values
are so large as to be useless for practical implementations (this is most
likely a typographical error, albeit one with technical consequences).
Proposed change: --- replace "2]" with "2*rnd_errorF]" and "4]" with
4*rnd_errorF]" respectively.

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

Comment number: --- USA-021
Clause/subclause, page #: --- 5.4.4 &5.4.5, 059 & 060
Category: ---  Q
Title: --- Choice of error bounds
Rationale: --- Need clear rationale for maximum error bounds for
round-to-nearest conversions.
Proposed change: --- The rationale for the use of 0.97 ulp as the upper
bound for these errors in IEEE 754 is based on a technical paper proving
that such accuracy is sufficient for converting back and forth from a given
floating type without incurring an error in the binary representation of the
original number. Accordingly, we ask either that the upper bound for such
errors be changed to 0.97ulp, or that an explanation be provided in B.5.4
for the difference.

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

Comment number: --- USA-022
Clause/subclause, page #: --- 5.5 Note, 062
Category: ---  e
Title: --- give specific reference
Rationale: --- above where?
Proposed change: --- after "above", specify "(5.4)"

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

Comment number: --- USA-023
Clause/subclause, page #: --- 5.5.2 paragraph 7, 062-063
Category: ---  m
Title: --- unnecessary requirement
Rationale: --- The requirements labeled a) and b) seem to require such
numerals, even in implementations that do not support the IEEE 754 standard.
Proposed change: --- Clarify that these numerals need only be provided for
implementations and bindings that support IEEE 754.

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

Comment number: --- USA-024
Clause/subclause, page #: --- B.3, 070
Category: ---  e
Title: --- remove unfortunate implication
Rationale: --- current wording implies IEEE754 is obsolete
Proposed change: --- reword as: 'The referenced IEC 60559 standard is
identical to IEEE 754 and the former IEC 559 standards.'

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

Comment number: --- USA-025
Clause/subclause, page #: --- B.5.1.2 paragraph 1 & B.5.2.2 paragraph 1, 072
& 076
Category: ---  e
Title: --- Improve explanation
Rationale: --- Improves rationale for Pole exception for empty list
Proposed change: --- Add words along the lines of: "Taking the
minimum/maximum of an empty sequence is an undefined operation. But since it
has a meaningful result (+INF/-INF), it is a pole exception, not an invalid
exception."

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

Comment number: --- USA-026
Clause/subclause, page #: --- B.5.1.7 paragraph 1, 073
Category: ---  e
Title: --- extraneous digits
Rationale: --- meaningless digits after "integers"
Proposed change: --- remove the "47"

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

Comment number: --- USA-027
Clause/subclause, page #: --- B.5.1.7 paragraph 1, 073
Category: ---  e
Title: --- Improve rationale
Rationale: --- Improved coverage of cases
Proposed change: --- add something like: "Overflow only happens on MIN / -1"

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

Comment number: --- USA-028
Clause/subclause, page #: --- B.5.1.8 paragraph 1, 074
Category: ---  e
Title: --- extraneous word
Rationale: --- "a" is repeated
Proposed change: --- remove one "a"

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

Comment number: --- USA-029
Clause/subclause, page #: --- B.5.2.3, 076
Category: ---  e
Title: --- Motivate controversial choice
Rationale: --- A controversial choice deserves an explanation. J11 prefers
that dim(+INF,+INF) and dim(-INF,-INF) return 0 rather than an
invalid(qNan).
Proposed change: --- Explain that LIA-2 interprets multiple different
instances of +/-INF as potentially representing different quantities, rather
than the same quantity. This allows the programmer to more easily detect
sources of errors.

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

Comment number: --- USA-030
Clause/subclause, page #: --- B.5.2.5 paragraph 2, 076
Category: ---  e
Title: --- misunderstanding of an assertion
Rationale: --- The original commenter suggests "cannot be exact" be changed
to "need not be exact". This reflects a misunderstanding - the sentence is
making an assertion about reality, not a requirement of an implementation
(reinterpreted from original suggestion).
Proposed change: --- Reword the sentence so its assertive nature is clear,
and indicates that its explanation is forthcoming.

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

Comment number: --- USA-031
Clause/subclause, page #: --- B.5.2.7, 077
Category: ---  e
Title: --- Add IEEE plug
Rationale: --- Clarify a difference between IEEE conforming and non IEEE
conforming implementations
Proposed change: --- Include a sentence explaining that add_loF() and
sub_loF() underflow only when denormals are not supported. Also, consider
adding a statement to the effect that, if the high part underflows, then the
low part is zero.

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

Comment number: --- USA-032
Clause/subclause, page #: --- B.5.3.5, 079
Category: ---  e
Title: --- cover all cases
Rationale: --- explanation is missing a useful fact
Proposed change: --- Add words like: "hypot() only underflows if both
arguments are denormal numbers.

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

Comment number: --- USA-033
Clause/subclause, page #: --- B.5.3.6, 079
Category: ---  e
Title: --- Which specification is being referred to?
Rationale: --- Pronoun use is ambiguous in its context
Proposed change: --- In the paragraph that mentions X/OPEN, change 'This
specification' to 'That specification'. Throughout the document, the term
"This specification" refers to itself, LIA-2. However, here, it is being
used to refer to the X/OPEN Portability Guide, thus it is confusing.
(alternate: "Those specifications")

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

Comment number: --- USA-034
Clause/subclause, page #: --- B.6 paragraph 1, 086
Category: ---  e
Title: --- imprecise use of English
Rationale: --- The use of "must not" here is understandable, but lacks the
explanatory power for which Annex B exists.
Proposed change: --- Reword sentence to explain in a neutral tone that
intermediate overflow is harmful to user programs and unnecessary in
implementations (wording changed from original suggestion).

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

Comment number: --- USA-035
Clause/subclause, page #: --- C, 094 &c
Category: ---  e
Title: --- inter-standard consistency
Rationale: --- Desire for LIA-2 to use consistent terminology with the IEEE
854 standard
Proposed change: --- Change 'SIGNAN' to 'NANS'. IEEE-854 suggests that all
representations of NAN (both quiet and signaling) start with the substring
'NAN', for ease of parsing the string representation of this symbol.

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

Comment number: --- USA-036
Clause/subclause, page #: --- C.3 next to last paragraph, 098
Category: ---  Q
Title: --- incompleteness
Rationale: --- Did someone intend complete a description of exception
numbers for BASIC?
Proposed change: --- Eliminate the "(?)" at the end of the 2nd to last
sentence.

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

Comment number: --- USA-037
Clause/subclause, page #: --- C.4 paragraph 1, 098
Category: ---  e
Title: --- update
Rationale: --- reference to C9x is not current. The FDIS was approved on
September 15, 1999, so it is now an IS. It is not clear when it will be
published.
Proposed change: --- When transmitting the Final CD to the editors, please
alert them to the need to amend this reference. Alternatively, it is up to
the editors at ISO/IEC to insure that inter-standard references are
up-to-date, as part of the publication process.

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

Comment number: --- USA-038
Clause/subclause, page #: --- C.4 max/min definitions, 099
Category: ---  e
Title: --- improve suggested binding
Rationale: --- C has a ternary operator to allow selection
Proposed change: --- Change 'imax(x,y)' to '(x<y ? y : x)'; also, change
'imin(x,y)' to '(x<y ? x : y)'

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

Comment number: --- USA-039
Clause/subclause, page #: --- C.4, 100
Category: ---  e
Title: --- improve readability
Rationale: --- separate unrelated groups of items in a list
Proposed change: --- Add a blank line between ceiling_rest and remr

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

Comment number: --- USA-040
Clause/subclause, page #: --- C.4 hypot section, 101
Category: ---  e
Title: --- imprecise reference to C
Rationale: --- The original C standard (1989) does not have a hypot()
Proposed change: --- Change "C has a hypot..." to "C9x has a hypot..."

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

Comment number: --- USA-041
Clause/subclause, page #: --- C.4 elementary floating operations list, 101
Category: ---  e
Title: --- imprecise references to C
Rationale: --- The original C standard does not have these functions
Proposed change: --- After the *, add "(C9x)" to the line for each of the
functions: exp2, log2, asinh, acosh, atanh, nearbyint

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

Comment number: --- USA-042
Clause/subclause, page #: --- C.4 "pow" discussion, 101
Category: ---  e
Title: --- improve completeness
Rationale: --- Note that pow() function in C is different in an additional
way from LIA-2
Proposed change: --- Need to consider pow(+/-1,+/-INF) in not qNaN in C9x

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

Comment number: --- USA-043
Clause/subclause, page #: --- C.4 convert section, 102-103
Category: ---  e
Title: --- choose symbol implying the proper type
Rationale: --- current representation implies misleading data type
Proposed change: --- Change '&r' to '&i'. Change 'x' to 'i'. The choice of
"r" and "x" symbols may imply a floating type to some people.

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

Comment number: --- USA-044
Clause/subclause, page #: --- C.4 following lists & C.5 following lists, 103
& 108
Category: ---  e
Title: --- unnecessary term definitions
Rationale: --- "?" is not used in the tables for C or C++
Proposed change: --- remove 'A ? above indicates that the parameter is
optional.' (for both C and C++ sections)

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

Comment number: --- USA-045
Clause/subclause, page #: --- C.4 3rd from last paragraph & C.5 3rd from
last paragraph, 103 & 108
Category: ---  e
Title: --- improve completeness
Rationale: --- In C and C++, the string form of floating point values may be
indicated by the presence of an exponent, as well as by the presence of a
".".

Proposed change: --- Change "must have a '.' in them" to "must have a '.' or
an exponent in them".

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

Comment number: --- USA-046
Clause/subclause, page #: --- C.5 paragraph 4, 104
Category: ---  e
Title: --- unfortunate hyphenation
Rationale: --- technical term can be read incorrectly
Proposed change: --- Change the hyphenation of "names-pace" to "name-space"

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

Comment number: --- USA-047
Clause/subclause, page #: --- C.5 lists, 104 & 105
Category: ---  e
Title: --- organization of tables
Rationale: --- easier for readers to find
Proposed change: --- move sqrt to after shift10, move mul to after sqrt_rest

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

Comment number: --- USA-048
Clause/subclause, page #: --- C.5 lists, 105
Category: ---  e
Title: --- misspelled function name
Rationale: --- easier for readers to find
Proposed change: --- Rename reciprocal_sqrt to rsqrt

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

Comment number: --- USA-049
Clause/subclause, page #: --- C.5 lists, 106 & 107
Category: ---  e
Title: --- excessive credit
Rationale: --- misleading status of C++ standard
Proposed change: --- Change the * to a dagger for the functions: asinh,
acosh, atanh, nearbyint

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

Comment number: --- USA-050
Clause/subclause, page #: --- C.5 convert-related entries, 107 & 108
Category: ---  e
Title: --- choice of conversion functions
Rationale: --- The idiomatic C++ syntax for triggering conversions to and
from digit strings is to use the overloaded << and >> 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:  [email-masked]