IEEE 754R minutes from October 17, 2002

• Attendance and minutes review
• Draft review
• Concluding notes and future meetings

Attendance and minutes review

• David Bindel (UCB)
• Mike Cowlishaw (IBM)
• Joe Darcy (Sun)
• Dick Delp (self)
• Mark Erle (IBM -- phone)
• Hossam Fahmy (Stanford)
• Eric Feng (Sun)
• David Hough (Sun)
• W. Kahan (UCB)
• Ren-Cang Li (Univ of Kentucky)
• Alex Liu (Sun)
• Peter Markstein (HP)
• Mike Parks (Sun)
• Jason Riedy (UCB)
• Eric Schwartz (IBM -- phone)
• David Scott (Intel)
• Jim Thomas (HP)
• Dan Zuras (self)

Hough corrected the spelling of Weitek in the September draft minutes. Otherwise, the minutes were accepted without modification.

Draft review

The draft review took roughly three and a quarter hours. We spent much of that time arguing over word choice and English usage. In particular, we discussed the following questions of usage:

• What terminology should we use for exceptions? Do we want to refer to exceptions, events, or exceptional events? Should exceptions signal or occur, or should we use both verbs with distinct technical meanings?
• Should we talk about the programmer, or the user? If our discussion of trapping serves mainly as advice to implementors of alternate exception handling, should we use the programmer to address that audience?
• Flags may convey more information than binary state. For instance, a raised flag might have an associated instruction pointer which indicates where the flag was first raised. Should we say a flag has two states, or do we need to be more careful to indicate that a flag contains, conveys, or has associated information? Do we need to speak about copying, restoring, or inspecting state associated with a flag, in addition to raising and lowering the flag?
• Do quiet NaNs propagate through algebraic operations, arithmetic operations, or just operations? What about bitwise operations, min and max, or conversion?
• Do we want to distinguish between synchronous and asynchronous traps, precise and imprecise traps, or scheduled and unscheduled control transfers?
• In the glossary, shall we specify the part of speech, either explicitly (by writing n or v next to a word), or by using each defined term in a sentence? This is particularly an issue for terms like signal, which, according to Webster's Unabridged, has eleven definitions and can serve as a noun, verb, or adjective.

We briefly discussed the default state of flags. Neither the original standard nor the current draft specify that flags are lowered at the start of execution. It is not always clear where the default state would apply -- for example, in an interactive environment, would the flags be cleared after each command? Similarly, when are retrospective diagnostics reported in an interactive program?

We also argued about signaling NaNs. In the proposed draft text, quiet operations signal no exception, even for optional signaling NaNs. Thomas, Riedy, Scott, and Darcy all pointed out peculiar situations where hardware supports signaling NaNs, but the language environment does not. When the language standard says nothing about signaling NaNs, it is unclear what will happen when a hardware signaling NaN appears. For instance, Darcy mentioned a Java bug in which a routine to return the bits of a floating point number malfunctioned on a signaling NaN input. Scott suggested a new trap or flag called NaN input. Kahan responded by asking how we would retrofit such a trap onto existing hardware.

Thomas pointed out that on the Itanium, it is actually more expensive to make quiet predicates signal when they encounter a signaling NaN.

We also argued about the all ones pattern for signaling NaNs. Scott and Thomas both pointed out that making the all-ones pattern a signaling NaN would break compatibility with all existing hardware. On the other hand, consider a blank Fortran common block initialized to the double signaling NaN pattern. The double signaling NaN bit pattern is the same as the bit pattern for a quiet single precision finite number followed by a quiet single precision NaN. If a primary purpose for signaling NaN is to find accesses to uninitialized untyped memory, the all ones pattern is a natural choice. Schwarz commented that all zeros would be also be a legitimate choice; that encoding represented a NaN in the initial decimal design.

There was a motion to change the should in appendix six into a shall. The original text read:

Signaling NaNs should be distinguished from quiet NaNs by the value of the most significant bit of the fraction field: 0 for signaling, 1 for quiet

Ten voted in favor, one voted against, and many abstained.

Signaling NaNs and Gentleman's technique

Kahan and several others were convinced that the technique Gentleman described for using signaling NaNs to represent missing data in statistical applications is a sufficiently useful application to warrant continued existence of signaling NaNs. Bindel was unconvinced, and suggested that the memory system could be used to implement the same technique with little more programming effort. Kahan stated that if we are to remove signaling NaNs from the standard, we must prove reasonable alternatives exist for situations where signaling NaN is now used. Bindel volunteered to try such an implementation, but noted that he might not get to it for a couple months.

Concluding notes and future meetings

Two committee members have final exams on the Thursday afternoon that was originally proposed for the December meeting. We agreed to tentatively move the date to Tuesday, 12/17; the meeting will still be at 1 pm in Santa Clara.

The November meeting will be at HP. We proposed min and max as the first topic after the draft review.

Hough noted that it is probably possible to have future meetings at Sun in rooms the same size as the October meeting room. Getting a larger room is nearly impossible.

Dan Zuras noted that Laurent Fournier of IBM Haifa, who works on verification, is interested in discussing a test suite.