From owner-sc22docs@dkuug.dk  Mon Jan  6 20:35:41 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.9.2/8.9.2) id UAA96928
	for sc22docs-domo; Mon, 6 Jan 2003 20:35:41 +0100 (CET)
	(envelope-from owner-sc22docs@dkuug.dk)
X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22docs@dkuug.dk using -f
Received: from email1.ansi.org (email1.ansi.org [12.15.192.17])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA96923
	for <sc22info@dkuug.dk>; Mon, 6 Jan 2003 20:35:38 +0100 (CET)
	(envelope-from mdeane@ANSI.org)
Received: by email1.ansi.org with Internet Mail Service (5.5.2653.19)
	id <T1YP2BC1>; Mon, 6 Jan 2003 14:31:23 -0500
Message-ID: <2F81C8110D55D411882A0020356797B2027FDE2D@email1.ansi.org>
From: Matthew Deane <mdeane@ANSI.org>
To: "'SC 22 Distribution List'" <sc22info@dkuug.dk>
Subject: SC 22 N 3534 - Summary of Voting on SC 22 N 3497, CD Approval Bal
	lot for ISO/IEC CD 10967-3
Date: Mon, 6 Jan 2003 14:31:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2B5BA.2CFF7980"
Sender: owner-sc22docs@dkuug.dk
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2B5BA.2CFF7980
Content-Type: text/plain;
	charset="iso-8859-1"

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:  mdeane@ansi.org

_____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.




------_=_NextPart_001_01C2B5BA.2CFF7980
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>SC 22 N 3534 - Summary of Voting on SC 22 N 3497, CD Approval =
Ballot for ISO/IEC CD 10967-3</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ISO/IEC JTC 1/SC22</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Programming languages, their =
environments and system software interfaces</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Secretariat:&nbsp; U.S.A.&nbsp; =
(ANSI)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ISO/IEC JTC 1/SC22 N3534</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">TITLE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Summary of Voting on SC 22 N =
3497, CD Approval Ballot for ISO/IEC CD 10967-3, Language independent =
arithmetic - Part 3:&nbsp; Complex integer and floating point =
arithmetic and complex elementary numerical functions</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DATE ASSIGNED:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">2003-01-06</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">SOURCE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">SC 22 Secretariat</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">BACKWARD POINTER:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">N/A</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DOCUMENT TYPE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Summary of Voting</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">PROJECT NUMBER:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">1.22.34</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">STATUS:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">The results of this ballot are =
forwarded to SC 22/WG 11 for review and appropriate action.&nbsp; This =
project has been registered at the CD stage on the SC 22 programme of =
work.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ACTION IDENTIFIER:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">ACT</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DUE DATE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">N/A</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DISTRIBUTION:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Text</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">CROSS REFERENCE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">SC 22 N3497</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DISTRIBUTION FORM:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Def</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Matt Deane</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">ANSI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">25 West 43rd Street</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">New York, NY&nbsp; 10036</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Telephone:&nbsp; (212) =
642-4992</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; (212) 840-2298</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Email:&nbsp; =
mdeane@ansi.org</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">_____end of cover page, =
beginning of document______________</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SUMMARY OF VOTING ON </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Letter Ballot Reference No:&nbsp; SC22 =
N3497<BR>
Circulated =
by:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; JTC 1/SC22<BR>
Circulation =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2002-09-23<BR>
Closing =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2002-12-24 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SUBJECT:&nbsp; Summary of Voting on =
SC 22 N3497, CD Approval Ballot for ISO/IEC CD 10967-3</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
------------- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The following responses have been =
received on the subject of approval: </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members supporting this =
appointment<BR>
8 (China, Czech Republic, Denmark, Republic of Korea, Netherlands, =
Norway, Russian Federation, Switzerland) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P&quot; Members supporting this =
appointment, with =
comments&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;<BR>
1 (Germany)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not supporting =
this appointment<BR>
2 (Japan, United Kingdom)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members =
abstaining&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
3 (Canada, France, USA) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not =
voting&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
10 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, =
Romania, Slovenia, Ukraine) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">___________ end of summary, beginning =
on NB comments _____________ </FONT>
</P>

<P><U><B><FONT FACE=3D"Arial">Germany</FONT></B></U><B></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Germany recognizes and greatly =
appreciates the huge time investment </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and effort by the editor to create =
the present document virtually </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">single-handedly.&nbsp; We believe the =
document is sufficiently mature to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">move to the CD stage.&nbsp; However, =
there are still a number of places </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">where the text is incomplete or =
inaccurate, and there still are </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">open questions which should be =
discussed by the committee.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At this point in time, Germany has not =
done a thorough reading of the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">whole document, but will comment on =
certain aspects nevertheless.&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">General remarks and questions: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-----------------------------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. In some cases a bit more (or even =
any) text to describe the general </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">behavior of a group of related =
operations/functions would be very </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">helpful, e.g. in 5.2.5: is one =
supposed to guess from the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">opeation's name, which is often =
abbreviated, what it is supposed to do, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">or do we really want everything to be =
deducible only from the math </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">specs?&nbsp; That seems to be a bit =
too terse.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. Also in 5.2.5 and maybe in other =
places, the role of -0 is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">virtually incomprehensible until one =
discovers the notes on page 7 --- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should we make this a bit more =
explicit or at least give a reference?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3. Also in 5.2.5, what is the reason =
for having re_F ?&nbsp; Only for NaNs?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">4. The signum fct is often defined =
with 3 result values in typical </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">math books: -1, 0, +1 .&nbsp; Do we =
want to have a nonzero result for a </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">zero argument?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5. There should be a rationale for the =
max_error_... parameters --- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">their choice is by no means obvious, =
and implementors will like to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">know how they were chosen.&nbsp; =
</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Corrections: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-----------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">7. In annex C.4 (Fortran binding), the =
syntax of the comparison </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">operator for equality (eq) should be =
=3D=3D and not =3D throughout.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">8. In annex C.4 (Fortran binding), the =
syntax for taking the real </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">part (re) is REAL and not =
REALPART.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">9. In annex C.4 (Fortran binding), the =
syntax for taking the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">imaginary part (im) is AIMAG and not =
IMAGPART (ugly, but that's </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the long tradition: intrinsic =
functions with a REAL result were </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not allowed to begin with any of the =
letters I through N because </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that would make their implicit result =
type INTEGER).&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">10. There are several other =
misspellings or syntax errors in </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">annex C.4 which we will communicate =
when the need arises.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">11. To complete annex C.4: Fortran =
provides complex I/O and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">complex literals in the form ( Re, Im =
) .&nbsp; </FONT>
</P>
<BR>

<P><U><B><FONT FACE=3D"Arial">Japan</FONT></B></U><B></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Japan disapproves CD 10967-3.&nbsp; =
The major reason is as follows.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The draft leaves unresolved several =
technical decisions necessary to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">constitute the final requirements of =
LIA-3.&nbsp; It contains place-holders</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to be filled in or even clauses that =
seem to be mere reminders to the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">editor himself,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; - There are many =
&quot;EDITOR'S NOTE&quot;s which are not intended to be read</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; by =
readers.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; - Many clauses, notably =
in Annexes B and C, contain only one line</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; which is =
&quot;...&quot;.&nbsp; Obviously, they are incomplete, and are to =
be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; filled =
in.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; - Clauses 5.3.2.2 -- =
5.3.3.13 have &quot;NOTE - TEMP&quot;.&nbsp; They are not notes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; but =
incomplete version of the definitions.&nbsp; They should be =
refined</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; and moved to =
the main text.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; - We can find many =
question marks in the text.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We must judge that the current =
version is incomplete.&nbsp; Decisions should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be made on the technical issues, and =
the draft should be refined accordingly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">before going to further stages of =
standardization of LIA-3.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Comments follow item by item.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Foreword</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The word &quot;organization&quot; and =
&quot;organisation&quot; are used interchangeably.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">They should be unified to =
&quot;organization&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Introduction, 3rd line of &quot;The =
content&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We think that the word =
&quot;-real&quot; in &quot;imaginary-real and complex-real</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">arithmetic&quot; should be changed to =
&quot;-floating-point&quot;.&nbsp; Its counterpart is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not &quot;imaginary&quot; nor =
&quot;complex&quot;, but is &quot;integer&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1.1, (c) and (d)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The order of function classes should =
be changed.&nbsp; In the main text,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">trigonometric functions appear before =
hyperbolic functions.&nbsp; Here their</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">order is different.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2., 3rd paragraph, last line</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The word &quot;takes&quot; should be =
changed to &quot;take&quot; in &quot;specifications ... takes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">precedence&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">4.1.5</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The definitions of i(X) and c(X) are =
not precise.&nbsp; For example, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">definitional equation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; i(X) =3D { ^i.y | y \in =
X }</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does not say, in mathematical sense, =
that i(x) has the same cardinality with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that of X when ^i. is an =
operator.&nbsp; It is not enough to simply say &quot;^i. is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a constructor&quot;.&nbsp; We need to =
put a definition clearly saying &quot;a constructor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">shall produce distinct values on its =
distinct argument values&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">4.1.5 says &quot;X may include special =
values&quot; in the definitions of i(X) and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">c(X).&nbsp; According to the =
interpretation above, we would consider that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">c(X) contains many special values =
such as sNaN+^i.qNaN, sNaN+^i.sNaN,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">etc., each distinct from other =
values.&nbsp; Is this the intent?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">4.1.5, 2nd paragraph, 1st line</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The word &quot;a&quot; should be =
changed to &quot;an&quot; in &quot;a imaginary&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5., 2nd paragraph</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;For each datatype, two of these =
... each: qNaN and sNaN.&quot; should be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;For each datatype, two of these =
abstract values, qNaN and sNaN, may</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">represent several actual =
values.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.1.1, the last sentence of =
NOTE</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The sentence beginning with =
&quot;Similarly below ...&quot; is grammatically</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">incomplete (does not have a =
verb).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.1.2</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The definitions of mul[i(I)] (p.14, =
4th definition from the bottom)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and mul[c(I)] (p.15, 4th definition =
from the top) are given in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a different style from other =
definitions.&nbsp; Other definitions give</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">values of real part and imaginary =
part separately.&nbsp; In other words,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">they use real arithmetic.&nbsp; Only =
these two definitions use complex</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">arithmetic.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The second and the third alternatives =
of eq[c(I)] (p.16, 1st definition)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are overlapping.&nbsp; Both contain =
the case eq[I](x,z) =3D false and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">eq[I](y,w) =3D false.&nbsp; =
Similarly, the first two alternatives of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">neq[c(I)] (p.16, the last definition) =
are overlapping.&nbsp; Both contain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the case neq[I](x,z) =3D true and =
neq[I](y,w) =3D true.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.1</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the specification of errors for =
approximation helper function h[c(F)],</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">expressions like Re( =
h[c(F)](Re(z)+^i.Im(z)) ) appear.&nbsp; According to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this expression, the signature of =
h[c(F)] should be c(F) *... -&gt; C.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">However, in the main text, say in =
5.3.2.2 for sin(z), signatures of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">functions are as follows.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; helper function : =
sin*[c(F)]: C[F] *... -&gt; C</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
operation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : sin[c(F)]:&nbsp; c(F) =
*... -&gt; c(F)..</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Both of these does not match to the =
signature in 5.2.1.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.1, Note 3</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The word &quot;an&quot; should be =
changed to &quot;a&quot; in &quot;an `rectangular'&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.2, 1st line</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The word &quot;requirement&quot; =
should be changed to plural.&nbsp; Apparently, there are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">two requirements.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.3, Note 1</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The phrase &quot;requirement =
apply&quot; is not grammatically correct.&nbsp; Probably,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;requirement&quot; should be =
&quot;requirements&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.4</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In an alternative of the definition of =
no_result[c(F)], the phrase &quot;at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">least one of x and y is a quiet =
NaN&quot; appears while in another alternative,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;at least one of x or y is a =
signalling NaN&quot; appears.&nbsp; The former uses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;and&quot; while the latter uses =
&quot;or&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the definition of =
no_result[i(f)-&gt;c(F)] (p.21, 2nd definition from the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">top), variables &quot;x&quot; and =
&quot;y&quot; appear in the right-hand side,&nbsp; They have no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">defining occurrences in the left-hand =
side.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the definition of no_result2[c(F)] =
(p.21, 3rd definition from the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">top), the second alternative applies =
when &quot;neither is a signalling NaN&quot;.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We think that &quot;neither&quot; =
should not be used when there are three or more</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">objects involved.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.5</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The signature of many functions, for =
example of add[i(F)], contains the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">set notation &quot;{ (underflow), =
overflow }&quot;.&nbsp; What is the meaning of these</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">parentheses around =
&quot;underflow&quot;?&nbsp; Since this is a mathematical =
notation,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">we feel that parentheses do not =
convey any meaning.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The definition of sub[F,i(F)] (p.23, =
3rd definition from the bottom)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">uses neg[F] function.&nbsp; =
Therefore, the value -0 may be generated as the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">result.&nbsp; The signature should be =
changed to &quot;... -&gt; c(F union { -0 }).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Similarly, the signature of =
sub[i(F),c(F)] (p.24, second definition from</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the top) should contain { -0 =
}.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The definition of sub[c(F)] (p.24, 4th =
definition from the top) replaces</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">x-z by x+(-z), in order to define =
subtraction.&nbsp; This is not consistent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with other definitions of =
&quot;sub&quot; functions.&nbsp; They directly define =
subtraction</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">without referring to addition.&nbsp; =
We think that it is not hard to define</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sub[c(F)] directly.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The signature of mul[F,i(F)] (p.24, =
6th definition from the top) contains</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">{ -0 } in its result.&nbsp; However, =
we cannot find in which case this special</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">value is generated.&nbsp; -0 would =
result when the argument is -0, but this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is not necessary to be =
mentioned.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the signature of div[i(F)] (p.25, =
2nd definition from the top) has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;union { -0 }&quot; in the =
domain of its second argument.&nbsp; This seems to be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a simple typo.&nbsp; It should be =
moved to the range of the result.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the definition of div[i(F),c(F)] =
(p.25, 7th definition from the top)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contains an expression =
re[F](y).&nbsp; This is not correct, since y is a real</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">value, and thus re[F](y) is y =
itself.&nbsp; The correct expression is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">re[i(F)](^i.y), meaning appropriately =
signed zero.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the definition of eq[F,i(F)] (p.25, =
3rd definition from the bottom),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">two values x+^i.0 and 0+^iw are =
compared.&nbsp; Shouldn't these zeros be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">changed to im[F](x) and =
re[i(F)](^i.w)?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The second and the third alternatives =
of eq[c(F)] (p.26, 5th definition</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from the top) are overlapping.&nbsp; =
Both contain the case where x =3D false</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and z =3D false.&nbsp; Similarly, =
alternatives of neq[c(F)] (p.27, 2nd definition</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from the top) are overlapping (both x =
and z are true).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is it necessary to define signum[F] =
(p.28, 5th definition from the top)?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Both the domain and the range of this =
function is real.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.2.6</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It says that two parameters =
box_error_mode_mul and box_error_mode_div</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should exist.&nbsp; But, the =
interpretation of values of these parameters</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is not specified.&nbsp; Only the =
statements such as &quot;max_error_mul interpreted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">according to the value of =
box_error_mode_mul&quot; appear in this section</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(similar statement exists for =
max_error_div).&nbsp; What happens when</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">box_error_mode_mul is true?&nbsp; =
What if false?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The definition of signum[c(F)] gives =
result when the value of its argument</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is -infinity, referring to the result =
when the argument is +infinity.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">However, there seems to be no =
definition for the +infinity case.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The phrase &quot;Further requirement =
... are&quot; appears in the sixth line from</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the bottom of p.29.&nbsp; The word =
&quot;requirement&quot; should be changed to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;requirements&quot;.&nbsp; The =
same phrase appears in many other sections.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3, 1st line</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">One of two &quot;of&quot;s should be =
removed from &quot;.... of of ...&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.2</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.3</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the definition of power[...] =
functions, there are many incorrect</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">usages of &quot;im&quot; =
function.&nbsp; Subexpressions such as &quot;im[F](y)&quot; and =
&quot;im[F](w)&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should be changed to =
&quot;re[i(F)](^i.y)&quot; and &quot;re[i(F)](^i.w)&quot;.&nbsp; The =
sign</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of zero is different.&nbsp; If the =
current text is intentionally written,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some notes would be necessary.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; p.33, 4th =
from the bottom (both y and w)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; p.33, 3rd =
from the bottom (y)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; p.33, 2nd =
from the bottom (w)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; p.34, 3rd =
from the top (y)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; p.34, 4th =
from the top (w)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.4</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the definition of =
sqrt[i(F)-&gt;c(F)] (p.35, 2nd definition from the top),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">re[i(F)](y) is not correct.&nbsp; It =
should be changed to re[i(F)](^i.y).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Since the re[i(F)] function takes =
purely imaginary value as its argument,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">its argument cannot be &quot;y&quot; =
(a real value).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.5</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For the definition of ln[i(F)-&gt;c(F)]=
 (p.36, 2nd definition from the top),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the same comment applies.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.5, Note 3, 3rd line</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The term &quot;principle value&quot; =
seems to be a typo.&nbsp; It would be &quot;principal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">value&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.6</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As in 5.3.1.3, the &quot;im&quot; =
function seems to be used incorrectly.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;im[F](y)&quot; and =
&quot;im[F](w)&quot; should be changed to =
&quot;re[i(F)](^i.y)&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and &quot;re[i(F)](^i.w)&quot;.&nbsp; =
Their positions are exactly corresponding to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.3.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.1.6</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The sentence &quot;A further =
requirement ... is ...&quot; should be changed to plural.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">There are two requirements.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.3.3</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The sentence &quot;Note that the =
correspondences specified below to other ISO/IEC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">10967 operations are exact, not =
approximate.&quot; looks strange.&nbsp; We cannot</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">understand the exact meaning of this =
sentence.&nbsp; If this sentence is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in fact necessary, it should be given =
as a general statement, not in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">context of a specific =
function.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5.5</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the first line, the sentence =
&quot;Rather than ..., imaginary units are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">specified.&quot; appears.&nbsp; Is =
this sentence a requirement?&nbsp; If so, it should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be phrased using =
&quot;shall&quot;.&nbsp; We cannot understand the status of this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sentence.</FONT>
</P>
<BR>
<BR>

<P><U><B><FONT FACE=3D"Arial">United Kingdom</FONT></B></U><B></B>
<BR><FONT FACE=3D"Times New Roman">The document still has comments like =
&quot;(mockup so far!)&quot; on page 107 and &quot;complex I/O =
!!!&quot; on page 108, and scanning for &quot;EDITOR'S NOTE&quot; will =
show up quite a number of unfinished sections, so we do not feel it is =
ready to go out to the public.<BR>
<BR>
On page 107 the statement &quot;Arithmetic value conversions<BR>
in Fortran are always explicit, and the conversion function is =
named<BR>
like the target type, except when converting to/from strings&quot; is =
doubly<BR>
incorrect. The first part has not been true since the advent of =
Fortran<BR>
77 and as for the names of type conversion functions, it really =
depends<BR>
what is meant by &quot;like&quot;.<BR>
<BR>
We are concerned by the growing size, and there are hints that<BR>
it is set to grow even bigger. We would prefer a small standard =
sooner<BR>
to an encyclopedia several years later.<BR>
<BR>
There is too much (near) repetition in the draft, so that it is<BR>
difficult to see and understand what is the same, and what is<BR>
different. In a program, clarity and simplicity would result by<BR>
defining and calling a procedure. A similar process here would give<BR>
similar benefits.<BR>
</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2B5BA.2CFF7980--