From listadm Tue Jan 7 10:10:32 2003 Received: from ace.ace.nl (ace.ace.nl [193.78.104.92]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id KAA07473 for ; Tue, 7 Jan 2003 10:10:27 +0100 (CET) (envelope-from willemw@ace.nl) Received: from wfw (tiwfw.ace.nl [192.168.106.12]) by ace.ace.nl (8.9.3/8.9.3) with SMTP id KAA03320 for ; Tue, 7 Jan 2003 10:07:08 +0100 Reply-To: From: "Willem Wakker" To: "SC22 WG11" Subject: WG11 N483 (aka SC 22 N 3534) Summary of Voting on SC 22 N 3497, CD Approval Ballot for ISO/IEC CD 10967-3 Date: Tue, 7 Jan 2003 10:11:10 +0100 Message-ID: <000501c2b62c$b8351ce0$0c6aa8c0@wfw.ace.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 FYI: the result of the LIA-3 CD ballot. Best regards, - WIllem Wakker. -----Original Message----- From: owner-sc22docs@dkuug.dk [mailto:owner-sc22docs@dkuug.dk] On Behalf Of Matthew Deane Sent: Monday, January 06, 2003 8:31 PM To: 'SC 22 Distribution List' Subject: (SC22docs.1870) SC 22 N 3534 - Summary of Voting on SC 22 N 3497, CD Approval Ballot for ISO/IEC CD 10967-3 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.