Public Comment Number PC-UK0163 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: Annex G, G.3 Title: Imaginary, complex infinities, NaNs and inexact Detailed description: The concept of a complex infinity is introduced under G.4.1 Multiplicative operators, which is bizarre. It should be moved up to the top of Annex G as one main point of IEEE 654 arithmetic and the LIA standards is consistency, and specifying it this way definitely encourages (and even requires) inconsistency. So the first part of G.4.1 paragraph 4 should be moved to G.1 and the following added: A complex number with one component a NaN and the other a finite number is a complex NaN. I can't say that I like this, because a complex NaN can turn into a complex infinity, which is the converse of the rule for real numbers. I would prefer the NaN property to take priority over the infinity one. G.3.2 Real and imaginary and G.3.3 Imaginary and complex are unnecessarily repetitive and forbid any consistent handling of NaNs and infinities. I suggest replacing them both by wording that cross-references the main body of the standard, such as: G.3.2 Imaginary, real and complex When a value of imaginary type is converted to a real or complex type, it is treated as if it were its corresponding real type, converted to its corresponding complex type, multiplied by _Complex_I and converted to the result type. When a value of real or complex type is converted to an imaginary type, it is treated as if it were multiplied by _Complex_I, and converted to the result type as if that were its corresponding real type. As mentioned under 6.2.1.6, the current wording is seriously incompatible with the spirit of IEEE 754 and LIA-1, in that information can be lost without flagging the fact in any way. With IEEE 754 arithmetic, the obvious way to indicate the loss of information is the inexact exception, but most people's experience is that is raised too often to be useful. However, it should be explicitly allowed. I suggest adding the following to G.3: 1 When a complex, real or imaginary finite or infinite number is converted to one of the other two forms and the converted number does not compare equal (as if using the == operator) to the original value, it is implementation-defined whether the inexact exception will be raised. 2 When a complex, real or imaginary NaN is converted to one of the other two forms and the converted number is not a NaN, it is implementation-defined whether one of the invalid or inexact exception will be raised and, if so, which. [ Note that conversion WITHOUT raising exceptions is provided by the creal and cimag functions, so this is not a restriction. ]