The IEEE 754R commitee met Feb 21, 2002 at Network Appliance. In attendence were:
Hearing no objections, the minutes from Jan 17 were accepted.
There were two proposed agenda items:
There were two major issues with the draft:
David Hough mentioned in our initial pass through the draft that signalling NaNs were originally intended to act as references, and mentioned that he'd written more detail in an e-mail sent to the list. Kahan pointed out that the authors of one statistical package used signalling NaNs on the 8087 to indicate unknown data, which could then be entered as needed. Signalling NaNs originally entered the standard for political reasons, but since they were there, someone found a use for them. Signalling NaNs are also potentially useful for retrospective diagnostics, but as yet Kahan has been able to convince a graduate student to write such software. Until the software is written and available, it is difficult to make a convincing case for its effectiveness. However, Kahan noted, he never received thanks from the scientists at Toronto for his improvements to their math library's accuracy; they only ever noticed and thanked him for the improved diagnostics.
Dan Zuras noted that there seemed to be three possible options to resolve the signalling copy issue: leave the trap behavior ambiguous, make it explicit that signalling NaNs trap on copy, or make it explicit that copy is a non-arithmetic operation and so does not trap. He questioned whether the scheme to which Kahan refered was worth the cost required to support it as part of the standard. Hough objected to leaving the text ambiguous; the objection was seconded by several others. One possibility would be to explicitly support both signalling and non-signalling variants in the standard. Kahan noted a historical precedence for providing both behaviors: on Crays, CDCs, and several other machines, there was a signalling version of copy which trapped on a special value (a negative zero).
Darcy, Riedy, and others noticed that if signalling NaNs were really used as references, then the objects to which they refer could theoretically be reference counted. In that case, it would be important to signal on copy in order to maintain correct reference counts.
Joe Darcy suggested that some of the functions of signalling NaNs could be mimiced by software. Kahan objected that such techniques would be ridiculously expensive; Darcy observed that traps were also quite expensive. Zuras noted that reasoning about the relative costs was tricky, and mentioned as an example a processor on which he worked which lost substantial overall SPEC performance due to an optimization which introduced traps on underflow. Jim Thomas pointed out that even in the common case when signalling NaNs are absent, the possibility of a signal could substantially increase execution cost by limiting the optimizations available to the (well-behaved) compiler. Hough noted that a proposal is in queue for a well-defined menu of trap options. Kahan noted that if programmers cannot write new trap handlers, then traps take on a limited character, and the performance tradeoffs become significant. He expressed doubt, though, that traps on signalling NaNs impose a significant extra burden when such traps as overflow and underflow are also possible.
Mike Cowlishaw made two observations regarding vocabulary. First, he noted that we should refer to the operation as "copy" instead of "assign", since assignment is subject to programming language context. For instance, in some languages assignment results in a changed binding or reference, but no data copy. Second, we might make a great deal of argument and confusion disappear by renaming signalling NaNs to "uninitialized values". Joe Darcy responded that in Java, at least, uninitialized data is strictly prohibited.
Dan Zuras tabled the issue of signalling copy until David Hough makes a proposal for modified text to the group.
There were two objections to the current version of table 4. First, it seemed that there were new names introduced for operators which, though listed under the C99 column, were not C99 functions. Second, and more important, not everyone thought columns for C99 and Fortran bindings belonged in the table at all. Those who thought the columns did belong disagreed on the role which they should play.
According to Dan Zuras, the original purpose of the table did
include controlling the meaning of
objected that this seemed out of scope. Besides, C99 and Fortran are
standardized; with luck, their definitions for these operators match
our definitions, but if they do not, we would not help by including
binding different bindings in our table. Besides, there are many languages
besides C and Fortran out there.
Hough, Zuras, and Darcy did not object strongly to retaining the Fortran and C99 names for the purpose of exposition. Hough noted that, while our names are not binding, we do need some names so that we can talk about the operations. If people build functions with the same names, of course, we hope they will use the same semantics.
Jim Thomas thought we should separate any statements about language bindings, even expository ones. We could, perhaps, put them in an annex. However, this is the wrong committee to standardize language bindings. Dan Zuras objected that we might want a language that supports the IEEE standard to at least support the obvious language bindings; Thomas reponded that not all language committees might think ours are the "obvious" bindings. Riedy worried that real headaches would ensue if one language had multiple implementations supporting different styles of bindings.
The proposed solution was to eliminate columns 2 through 4 of table 4, and at a later date revisit the issue of language bindings. There were no objections to this proposal, though David Hough noted that he will leave blank space in place of the removed columns, since Star Office makes it difficult to remove columns from an existing table. Jason Riedy and Jim Thomas agreed to attack the question of language bindings. While language bindings as a general topic are interesting, we will likely focus specifically on the relations in table 4 first.
Hough's draft text was accepted as amended.
Riedy and Delp objected to using 32 bit integers for the results from ilogb, since languages like Dylan and Ruby use smaller integers in order to reserve bits for type tags. Kahan observed that 23 bits would probably be adequate; seventeen bits for exponent, 219 for infinity, bigger for NaN. We will want to touch on this again if we work with precisions beyond quad. Zuras noted that 31 bits will probably be adequate for the foreseeable future, and proposed +/-228 for infinity and 230 for NaN.
We argued about what to do on gross overflows and underflows in calls to scalb. Hough will come up with specific wording next time. Kahan would like to save the architect thr trouble of saving operands after the operation is launched; but over / underflow can only be detected at the end of an operation. Hough stated that whatever we say will apply to all instances of over / underflow that can't be trapped. This will result in changes in decimal to binary conversion as well (particularly since decimal to binary conversion might well use scalb internally).
David Scott pointed out that there are some questions about the behavior of setexponent if the specified exponent is out of range or subnormal. David Hough stated that setexponent is a non-arithmetic operation, only meant for bit-twiddling. If N is not in range, we will just use the least significant bits. Kahan said setexponent is really a suggestion to the hardware people for things that we want. Darcy asked whether these operations are useful at the programmer level, and if so, whether we should say something separate to hardware implementaors. Kahan suggested that we might want to say explicitly in our description which features we want specifically in order to support other features. Hough noted that hardware folks looking at our specification of ilogb will probably dismiss it without a second thought, but might at least consider giving support to operations like setexponent. Delp suggested that we remove the world "field" (which implies the bits, including the bias), and instead talk about the unbiased exponent.
Kahan asked whether these functions are obligitory, or optional as before.
Hough, Kahan, and Riedy all presented their drafts of a classification function. The drafts were very similar; the three draft authors will confer offline and present a unified draft in March.
Delp asked whether the classification functions as proposed match current practice, or if they are just made up. David Scott replied that Intel does have masked predicates which are similar. Delp asked if we were sure this was the right way to do things, and if we expected to require fclass for conforming implementations. We decided that, for the moment, we will call it recommended.
Kahan pointed out the potential usefulness of fclass masks for implementing quiet functions, and silent ordering predicates. Zuras noted that it might help our discussions of table 4 to define operations in terms of the necessary fclass masks. Kahan's mask bits differed from Hough's only in that Hough's had a bit for distinguishing between > 1 and < 1, and Kahan's had a bit for distinguishing "not a floating point representation."
The primary difference between Jason's proposal and the proposals of Kahan and Hough was that Jason proposed two separate functions: one to get the classification, and another to test it.
Meetings are scheduled for