Subject: SC 22 N 3534 - Summary of Voting on SC 22 N 3497, CD Approval Bal lot for ISO/IEC CD 10967-3

From: Matthew Deane <[email-masked]>
Date: Mon, 6 Jan 2003 14:31:14 -0500

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N3534

TITLE:
Summary of Voting on SC 22 N 3497, CD Approval Ballot for ISO/IEC CD
10967-3, Language independent arithmetic - Part 3:  Complex integer and
floating point arithmetic and complex elementary numerical functions

DATE ASSIGNED:
2003-01-06

SOURCE:
SC 22 Secretariat

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Summary of Voting

PROJECT NUMBER:
1.22.34

STATUS:
The results of this ballot are forwarded to SC 22/WG 11 for review and
appropriate action.  This project has been registered at the CD stage on the
SC 22 programme of work.

ACTION IDENTIFIER:
ACT

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC 22 N3497

DISTRIBUTION FORM:
Def

Matt Deane
ANSI
25 West 43rd Street
New York, NY  10036
Telephone:  (212) 642-4992
Fax:             (212) 840-2298
Email:  [email-masked]

_____end of cover page, beginning of document______________

SUMMARY OF VOTING ON 

Letter Ballot Reference No:  SC22 N3497 
Circulated by:                JTC 1/SC22 
Circulation Date:            2002-09-23
Closing Date:                 2002-12-24 
SUBJECT:  Summary of Voting on SC 22 N3497, CD Approval Ballot for ISO/IEC
CD 10967-3
---------------------------------------------------------------------- 
The following responses have been received on the subject of approval: 

"P" Members supporting this appointment 
8 (China, Czech Republic, Denmark, Republic of Korea, Netherlands, Norway,
Russian Federation, Switzerland) 

P" Members supporting this appointment, with comments              
1 (Germany)        

"P" Members not supporting this appointment 
2 (Japan, United Kingdom)

"P" Members abstaining                    
3 (Canada, France, USA) 

"P" Members not voting                    
10 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea,
Romania, Slovenia, Ukraine) 

___________ end of summary, beginning on NB comments _____________ 

Germany
Germany recognizes and greatly appreciates the huge time investment 
and effort by the editor to create the present document virtually 
single-handedly.  We believe the document is sufficiently mature to 
move to the CD stage.  However, there are still a number of places 
where the text is incomplete or inaccurate, and there still are 
open questions which should be discussed by the committee.  

At this point in time, Germany has not done a thorough reading of the 
whole document, but will comment on certain aspects nevertheless.  

General remarks and questions: 
-----------------------------

1. In some cases a bit more (or even any) text to describe the general 
behavior of a group of related operations/functions would be very 
helpful, e.g. in 5.2.5: is one supposed to guess from the 
opeation's name, which is often abbreviated, what it is supposed to do, 
or do we really want everything to be deducible only from the math 
specs?  That seems to be a bit too terse.  

2. Also in 5.2.5 and maybe in other places, the role of -0 is 
virtually incomprehensible until one discovers the notes on page 7 --- 
should we make this a bit more explicit or at least give a reference?  

3. Also in 5.2.5, what is the reason for having re_F ?  Only for NaNs?  

4. The signum fct is often defined with 3 result values in typical 
math books: -1, 0, +1 .  Do we want to have a nonzero result for a 
zero argument?  

5. There should be a rationale for the max_error_... parameters --- 
their choice is by no means obvious, and implementors will like to 
know how they were chosen.  

6. From my former colleagues' experience in implementing the complex 
functions for IBM's ACRITH (High Accuracy Arithmetic) Library, there 
is no way to implement the general case of the complex power function 
using a fixed, predetermined internal format if you want to guarantee 
a certain error bound in all cases.  The real and imaginary parts of 
the result of the complex power fct are basically real functions with 
4 real parameters, and the trig fcts kill your error estimates because 
you don't know how close their arguments might get to critical values, 
e.g. to certain mulltiples of pi/2.  So it is not at all clear how 
and if any implementor can achieve max_error_power <= 7 .  

Corrections: 
-----------

7. In annex C.4 (Fortran binding), the syntax of the comparison 
operator for equality (eq) should be == and not = throughout.  

8. In annex C.4 (Fortran binding), the syntax for taking the real 
part (re) is REAL and not REALPART.  

9. In annex C.4 (Fortran binding), the syntax for taking the 
imaginary part (im) is AIMAG and not IMAGPART (ugly, but that's 
the long tradition: intrinsic functions with a REAL result were 
not allowed to begin with any of the letters I through N because 
that would make their implicit result type INTEGER).  

10. There are several other misspellings or syntax errors in 
annex C.4 which we will communicate when the need arises.  

11. To complete annex C.4: Fortran provides complex I/O and 
complex literals in the form ( Re, Im ) .  

Japan
Japan disapproves CD 10967-3.  The major reason is as follows.

The draft leaves unresolved several technical decisions necessary to
constitute the final requirements of LIA-3.  It contains place-holders
to be filled in or even clauses that seem to be mere reminders to the
editor himself,

   - There are many "EDITOR'S NOTE"s which are not intended to be read
     by readers.

   - Many clauses, notably in Annexes B and C, contain only one line
     which is "...".  Obviously, they are incomplete, and are to be
     filled in.

   - Clauses 5.3.2.2 -- 5.3.3.13 have "NOTE - TEMP".  They are not notes
     but incomplete version of the definitions.  They should be refined
     and moved to the main text.

   - We can find many question marks in the text.
  
We must judge that the current version is incomplete.  Decisions should
be made on the technical issues, and the draft should be refined accordingly
before going to further stages of standardization of LIA-3.

Comments follow item by item.

Foreword

The word "organization" and "organisation" are used interchangeably.
They should be unified to "organization".

Introduction, 3rd line of "The content"

We think that the word "-real" in "imaginary-real and complex-real
arithmetic" should be changed to "-floating-point".  Its counterpart is
not "imaginary" nor "complex", but is "integer".

1.1, (c) and (d)

The order of function classes should be changed.  In the main text,
trigonometric functions appear before hyperbolic functions.  Here their
order is different.

2., 3rd paragraph, last line

The word "takes" should be changed to "take" in "specifications ... takes
precedence".

4.1.5

The definitions of i(X) and c(X) are not precise.  For example, the
definitional equation
   i(X) = { ^i.y | y \in X }
does not say, in mathematical sense, that i(x) has the same cardinality with
that of X when ^i. is an operator.  It is not enough to simply say "^i. is
a constructor".  We need to put a definition clearly saying "a constructor
shall produce distinct values on its distinct argument values".

4.1.5 says "X may include special values" in the definitions of i(X) and
c(X).  According to the interpretation above, we would consider that
c(X) contains many special values such as sNaN+^i.qNaN, sNaN+^i.sNaN,
etc., each distinct from other values.  Is this the intent?

4.1.5, 2nd paragraph, 1st line

The word "a" should be changed to "an" in "a imaginary".

5., 2nd paragraph

"For each datatype, two of these ... each: qNaN and sNaN." should be
"For each datatype, two of these abstract values, qNaN and sNaN, may
represent several actual values."

5.1.1, the last sentence of NOTE

The sentence beginning with "Similarly below ..." is grammatically
incomplete (does not have a verb).

5.1.2

The definitions of mul[i(I)] (p.14, 4th definition from the bottom)
and mul[c(I)] (p.15, 4th definition from the top) are given in
a different style from other definitions.  Other definitions give
values of real part and imaginary part separately.  In other words,
they use real arithmetic.  Only these two definitions use complex
arithmetic.

The second and the third alternatives of eq[c(I)] (p.16, 1st definition)
are overlapping.  Both contain the case eq[I](x,z) = false and
eq[I](y,w) = false.  Similarly, the first two alternatives of
neq[c(I)] (p.16, the last definition) are overlapping.  Both contain
the case neq[I](x,z) = true and neq[I](y,w) = true.

5.2.1

In the specification of errors for approximation helper function h[c(F)],

expressions like Re( h[c(F)](Re(z)+^i.Im(z)) ) appear.  According to
this expression, the signature of h[c(F)] should be c(F) *... -> C.
However, in the main text, say in 5.3.2.2 for sin(z), signatures of
functions are as follows.
   helper function : sin*[c(F)]: C[F] *... -> C
   operation       : sin[c(F)]:  c(F) *... -> c(F)..
Both of these does not match to the signature in 5.2.1.

5.2.1, Note 3

The word "an" should be changed to "a" in "an `rectangular'".

5.2.2, 1st line

The word "requirement" should be changed to plural.  Apparently, there are
two requirements.

5.2.3, Note 1

The phrase "requirement apply" is not grammatically correct.  Probably,
"requirement" should be "requirements".

5.2.4

In an alternative of the definition of no_result[c(F)], the phrase "at
least one of x and y is a quiet NaN" appears while in another alternative,
"at least one of x or y is a signalling NaN" appears.  The former uses
"and" while the latter uses "or".

In the definition of no_result[i(f)->c(F)] (p.21, 2nd definition from the
top), variables "x" and "y" appear in the right-hand side,  They have no
defining occurrences in the left-hand side.

In the definition of no_result2[c(F)] (p.21, 3rd definition from the
top), the second alternative applies when "neither is a signalling NaN".
We think that "neither" should not be used when there are three or more
objects involved.

5.2.5

The signature of many functions, for example of add[i(F)], contains the
set notation "{ (underflow), overflow }".  What is the meaning of these
parentheses around "underflow"?  Since this is a mathematical notation,
we feel that parentheses do not convey any meaning.

The definition of sub[F,i(F)] (p.23, 3rd definition from the bottom)
uses neg[F] function.  Therefore, the value -0 may be generated as the
result.  The signature should be changed to "... -> c(F union { -0 }).
Similarly, the signature of sub[i(F),c(F)] (p.24, second definition from
the top) should contain { -0 }.

The definition of sub[c(F)] (p.24, 4th definition from the top) replaces
x-z by x+(-z), in order to define subtraction.  This is not consistent
with other definitions of "sub" functions.  They directly define subtraction
without referring to addition.  We think that it is not hard to define
sub[c(F)] directly.

The signature of mul[F,i(F)] (p.24, 6th definition from the top) contains
{ -0 } in its result.  However, we cannot find in which case this special
value is generated.  -0 would result when the argument is -0, but this
is not necessary to be mentioned.

In the signature of div[i(F)] (p.25, 2nd definition from the top) has
"union { -0 }" in the domain of its second argument.  This seems to be
a simple typo.  It should be moved to the range of the result.

In the definition of div[i(F),c(F)] (p.25, 7th definition from the top)
contains an expression re[F](y).  This is not correct, since y is a real
value, and thus re[F](y) is y itself.  The correct expression is
re[i(F)](^i.y), meaning appropriately signed zero.

In the definition of eq[F,i(F)] (p.25, 3rd definition from the bottom),
two values x+^i.0 and 0+^iw are compared.  Shouldn't these zeros be
changed to im[F](x) and re[i(F)](^i.w)?

The second and the third alternatives of eq[c(F)] (p.26, 5th definition
from the top) are overlapping.  Both contain the case where x = false
and z = false.  Similarly, alternatives of neq[c(F)] (p.27, 2nd definition
from the top) are overlapping (both x and z are true).

Is it necessary to define signum[F] (p.28, 5th definition from the top)?
Both the domain and the range of this function is real.

5.2.6

It says that two parameters box_error_mode_mul and box_error_mode_div
should exist.  But, the interpretation of values of these parameters
is not specified.  Only the statements such as "max_error_mul interpreted
according to the value of box_error_mode_mul" appear in this section
(similar statement exists for max_error_div).  What happens when
box_error_mode_mul is true?  What if false?

The definition of signum[c(F)] gives result when the value of its argument
is -infinity, referring to the result when the argument is +infinity.
However, there seems to be no definition for the +infinity case.

The phrase "Further requirement ... are" appears in the sixth line from
the bottom of p.29.  The word "requirement" should be changed to
"requirements".  The same phrase appears in many other sections.

5.3, 1st line

One of two "of"s should be removed from ".... of of ...".

5.3.1.2

In the requirement on the relationship with real-valued functions, the
term "library" is used.  We feel that such a concrete notion should not
appear in the context of specific functions.  Isn't it possible to give
such definitions in Clause 4., or some appropriate place?  Sentences
such as "The requirements implied by the relationships and the requirements
from part 2 shall hold even if there is no ... operations in any associated
library for real-valued operations or there is no associated library
for real-valued operations" are given for many functions.  Isn't it
possible to give a single meta-requirement for this?

5.3.1.3

In the definition of power[...] functions, there are many incorrect
usages of "im" function.  Subexpressions such as "im[F](y)" and "im[F](w)"
should be changed to "re[i(F)](^i.y)" and "re[i(F)](^i.w)".  The sign
of zero is different.  If the current text is intentionally written,
some notes would be necessary.

     p.33, 4th from the bottom (both y and w)
     p.33, 3rd from the bottom (y)
     p.33, 2nd from the bottom (w)
     p.34, 3rd from the top (y)
     p.34, 4th from the top (w)

5.3.1.4

In the definition of sqrt[i(F)->c(F)] (p.35, 2nd definition from the top),
re[i(F)](y) is not correct.  It should be changed to re[i(F)](^i.y).
Since the re[i(F)] function takes purely imaginary value as its argument,
its argument cannot be "y" (a real value).

5.3.1.5

For the definition of ln[i(F)->c(F)] (p.36, 2nd definition from the top),
the same comment applies.

5.3.1.5, Note 3, 3rd line

The term "principle value" seems to be a typo.  It would be "principal
value".

5.3.1.6

As in 5.3.1.3, the "im" function seems to be used incorrectly.
"im[F](y)" and "im[F](w)" should be changed to "re[i(F)](^i.y)"
and "re[i(F)](^i.w)".  Their positions are exactly corresponding to
5.3.1.3.

5.3.1.6

The sentence "A further requirement ... is ..." should be changed to plural.
There are two requirements.

5.3.3

The sentence "Note that the correspondences specified below to other ISO/IEC
10967 operations are exact, not approximate." looks strange.  We cannot
understand the exact meaning of this sentence.  If this sentence is
in fact necessary, it should be given as a general statement, not in the
context of a specific function.

5.5

In the first line, the sentence "Rather than ..., imaginary units are
specified." appears.  Is this sentence a requirement?  If so, it should
be phrased using "shall".  We cannot understand the status of this
sentence.

United Kingdom
The document still has comments like "(mockup so far!)" on page 107 and
"complex I/O !!!" on page 108, and scanning for "EDITOR'S NOTE" will show up
quite a number of unfinished sections, so we do not feel it is ready to go
out to the public.

On page 107 the statement "Arithmetic value conversions
in Fortran are always explicit, and the conversion function is named
like the target type, except when converting to/from strings" is doubly
incorrect. The first part has not been true since the advent of Fortran
77 and as for the names of type conversion functions, it really depends
what is meant by "like".

We are concerned by the growing size, and there are hints that
it is set to grow even bigger. We would prefer a small standard sooner
to an encyclopedia several years later.

There is too much (near) repetition in the draft, so that it is
difficult to see and understand what is the same, and what is
different. In a program, clarity and simplicity would result by
defining and calling a procedure. A similar process here would give
similar benefits.