IEEE 754R minutes from July 22, 2002

Attendance and minutes review

The IEEE 754R committee met August 22, 2002 at HP. In attendance were:

There was one point in the July minutes where the word "overflow" should have been "underflow." Otherwise, the minutes were approved as drafted.


Having observed that the past year's worth of discussions regarding the predicate table essentially went in circles, David Hough decided to propose a completely different organization of the material. He drafted three tables to replace table 4: a table of quiet predicates required for all implementations, a table of required signaling predicates for older programs, and and a table of required quiet predicates for new programs and languages. Each table includes information about the predicate names, symbols, and negations. There are ten additional predicates not mentioned in the tables, which Hough put in purple at the end of his text; most of those predicates we can probably do without. The text around the tables is mostly the same as the text from the most recent single-table draft.

Hough asked whether we would be willing to accept the proposed restructuring and work on it for the next few meetings instead of continuing to talk circles around the original table 4. We unanimously agreed to work on the restructured text.

Draft review

Rick James asked why the symbol ">" appeared in multiple tables. Hough replied that it was the distinction between old programs and new programs: the same symbol is used by both the just and the wicked (or the signaling and the quiet) to denote slightly different concepts.

Zuras asked whether the revised text specifies that quiet is preferred. Hough replied that old programs can use signaling predicates, but the new ones should use quiet predicates. Zuras asked whether the criterion should be based on the date; Hough replied that different people achieve 754-enlightenment at different times. Delp objected that the wording was unclear. Kahan proposed that we could recommend quiet predicates for languages which "take account of NaNs," or possibly languages "that provide bindings," while Zuras thought we might specify languages that "support this revision."

We know that programming languages oblivious to NaNs exist, and we generally agreed that it is important to acknowledge them. We disagreed about the preferred default, either for supporting old programming languages or for the design of new languages. Hough thought new languages should default to quiet operations; Kahan thought new languages should default to signaling comparisons.

We briefly discussed the choice of symbols in the tables. Jim Thomas noted that we had been ambivalent about whether we were suggesting language bindings or just trying to make the tables as clear as possible. Riedy suggested that we could state that the symbols are included for illustrative purposes only.

Hough asked what the committee thought of the symbol "<>." Kahan and some others objected that "<>" is already used to denote "not equal" in languages like Pascal and BASIC. Zuras suggested removing the symbol, but leaving the table entry. Hough thought we should replace the symbol with "!=?." Kahan suggested that we table the issue, since the fate of that line is uncertain anyhow. Hough noted that the predicate is useful sometimes, but not often. He thought he had used it to sort out arguments to transcendental functions, but did not remember the details.

Thomas suggested we include the C99-style predicate names. Zuras replied that the group collectively objected to such names more than once. At various points, the tables included both C and Fortran bindings. Cowlishaw observed that the point of earlier objections was that including language-dependent entries made the tables seem less valuable to writers of other languages. Thomas thought another reasonable approach would be to take out the symbolic notation and just include English descriptions of the predicates. Hough stated his preference for the bang notation, since it is clearly abstractly suggestive rather than a concrete language binding recommendation. Hinds noted that he found the C99 names helpful. Hough agreed to add the C99 names back into the tables, and to make the symbols for different predicates distinct.

Hough noted that footnote 6 makes more sense after the tables. Rick James had pointed out that the footnote just repeats what has been said before in different words. Hinds asked whether we were suggesting a language binding in our use of "NOT." James pointed out that we had a notational problems, since we had two types of negation. Jim Thomas suggested that we might illustrate the point more clearly with C or Fortran syntax. Rick James noted that making "=" a special case caused additional confusion, and Hough suggested that we move the text for "=" to the end and add words explaining it as an unusual case.

Having finished our monthly discussion of predicates, we turned to signaling NaNs. Hough noted that if we were to use signaling NaNs as pointers to numbers, we would need copy operations to keep the sign. Hough also stated that he had been converted to the point of view that all memory should be initialized to all 1s in order to detect uninitialized data. Kahan thought the discussion should be postponed until after the presentation by Bindel and Riedy.

Exception handling

Bindel and Riedy spoke about language-level exception handling mechanisms and their implementation, and gave some suggestions about what exception handling support should be specified in 754R. The presentation closely followed the slides, though Thomas and Darcy asked some clarifying questions regarding interactions with presubstitution and the type system.

We began the follow-up discussion by returning to the topic of signaling NaNs. Some people do use signaling NaNs for debugging, but Hough mentioned that the cost of dealing with signaling NaNs is very high when implementing elementary transcendentals, and Thomas noted that the C99 committee tried for years to include support for signaling NaNs, but ultimately decided it was not worth the effort.

There was general consensus that we would like to deprecate signaling NaNs, but that we did not want to break existing implementations or codes. Delp and Hinds both expressed concern about breaking current support, though several people countered by pointing out that signaling NaNs are already not portable. We decided it would only be due diligence to check how people use signaling NaNs before deprecating them. Jim Thomas agreed to ask the C99 committee for user feedback; David Hough agreed to ask Larry Meadows of the Fortran committee for similar feedback; David Scott agreed to scan Google search listings; and Riedy agreed to post to comp.arch, comp.arith, and other relevant newsgroups. Delp suggested we specify a time for feedback, and Zuras recommended next month. Jim Thomas noted that the feedback from language liaisons might take longer than that.

We also discussed how to change the wording of the standard to deprecate NaNs. Darcy suggested that the description of signaling NaN behavior be moved to an informative annex. Hough suggested that we remove the text requiring "at least one signaling NaN," and say that all NaNs should be quiet. Hough then moved that we remove the requirement for signaling NaNs, provided, having done due diligence, we satisfy ourselves that no harm will be done. The motion was accepted.

Bindel suggested that we remove traps from the standard as well. Kahan noted that when traps were described in the standard, part of the motivation was to guide hardware people on two issues: what information should be provided when dealing with exceptions, and why traps need not be precise (a point which has been obscured somewhat). Kahan thought this advice was regarded as helpful by hardware implementors, and that it is needed by software writers as well. He mentioned that some past designers have done the wrong thing with floating point traps for lack of guidance, and suggested that we should ask hardware designers how much they got from the discussion of trapping before we removed it.

Kahan also stated that he thought it a terrible irony that hardware designers go to great lengths to make floating-point traps precise, but code motion and other optimizations performed by modern compilers make the traps appear imprecise at a language level. Darcy replied that this depends a lot on the language. Ada has imprecise exceptions, for instance, and Java has precise exceptions. Java's language-level precise exceptions can be implemented by respecting safe synchronization points, though, and optimization of code between safe points does not change the program semantics. Kahan objected that even with safe points, you will not know where your exception occured unless you know every instruction, or unless you incorporate milestone markers into your code. Darcy responded that in many cases you can get some information about where the exception occurred by checking a loop index, for example.

Hough moved that we put traps into an appendix, noting that he definitely intended to propose putting alternate exception handling in chapter 8. Kahan objected that the distinction between trapped and flagged underflow should remain in the body of the text. After some further debate, Bindel moved that we put section 8 into an appendix, leaving discussion of the distinction between trapped and flagged underflow where it is, to be revisited later. There were no objections.

Static exception handling

For the remaining few minutes, Hough spoke about his proposal for static specification of exception handling. Hough said his proposal involved three points:

We ran out of time before much coherent discussion could take place, though Kahan said "Oh! Not quite!" to some point, I recall not which, and Riedy stated that he thought he might have ideas on a better way to handle the same issues.

Future meetings

September will be a hardware meeting. Professor Kahan is scheduled to talk at the beginning of the meeting about hardware implementation of gradual underflow.

Upcoming meetings are

754 | revision | FAQ | references