IEEE 754R minutes from March 20, 2003

Attendance and minutes review

The IEEE 754R committee met at HP Palo Alto on March 20, 2003. In attendance were

The February meeting minutes were distributed early, and many did not remember them by the time of the March meeting. Consequently, they were accepted without comment.

In the interest of coherence, these minutes (for March 20) are ordered by topic rather than by order of discussion.

Agenda review

Since many of the bullets on our long-term agenda are months or years old, we decided to review the list of agenda items. The original list included the following:

Expression evaluation (Kahan, Riedy)
Exception names (Kahan, Hough)
Static modes (Hough)
Integer format (Hough)
Unified integer description (?)
Extended data types in general (Hough)
Tower of precisions and generalized test vectors (Zuras)
Binary-to-decimal conversion (Darcy)
A character for unordered (Kahan)
Source code faithful exceptions and modes (Kahan)
Scope proposals (Hough, Thomas)
FMA directives (?)
Why not combine wider operands into narrow results?  (Markstein)
Languages: to bind or not to bind? (Riedy, Thomas)
Decimal arithmetic (Cowlishaw)
Semantics of recommended functions (Darcy)
Sign of max(+0,-0) (Darcy, Thomas)

We decided the unified integer description item is no longer relevant, since we've already been doing it. The tower of precisions was discarded several meetings ago, as was the notion of names of the new precisions; however, test vector development remains relevant. The character for unordered was a table 4 issue; since we have (we all fervently hope) concluded discussions of table 4, this item can be removed.

Many of the agenda items are subsumed by or closely related to expression evaluation disciplines. In particular, our discussions of integer formats, source code faithful expressions and modes, and FMA directives are all related to the expression evaluation discussion. Issues of alternate exception handling should also be deferred until after the expression evaluation discussion.

Binary-to-decimal conversion may now involve either textual encoding or format conversion. The textual representations of infinity and NaN are still unresolved. Hauser also pointed out that some existing standards (C99) include support for NaN significand representation.

The discussion of expression evaluation should be soon, but it has not yet been specifically scheduled. Kahan suggested that we invite some more language experts when we do have that discussion. The decimal meeting will be in May to accommodate Cowlishaw's schedule. Darcy would like to discuss unresolved issues involving recommended function semantics sooner rather than later, since they impact the next Java revision. Thomas wanted to finish off min/max, and particularly the sign of min or max(+0,-0)). Though the min/max discussion seemed largely complete, Hauser expressed dissatisfaction with the choice we made of max(NaN, k) = k and Riedy pointed out that we have not resolved min/max with respect to NaN significands and signaling behavior. Riedy and Thomas agreed to defer the discussion of language bindings until some other issues have been resolved.

Draft review

Extended formats

After re-iterating his belief that nobody will implement an extended format beyond the existing ones, Hough asked whether his revised description of the extended formats met with general approval.

We briefly discussed whether decimal extended formats should be supported in the standard at all. Kahan gave examples of computations made easier by the presence of an extended format, including matrix computations (particularly iterative refinement), decimal-to-binary conversion, and exponential computations over the full range.

Someone asked about the level of support for extended formats in C99. Thomas replied that the C99 standard has two levels of specification: the basic level and the IEEE level. Depending on which recommended features of C99 an implementation includes, long double could be a double extended type or not.

Kahan suggested that, in light of the increase in exponent range, the decimal64 extended should be 20 digits rather than 19. Schwarz felt we should specify a minimum precision of 3n+1 digits, since that is the number of digits afforded by the DPD encoding. Kahan thought it mattered little, since extended formats are unlikely to be packed in the same way as the basic formats. This statement led to a brief debate on whether or not data would be stored in packed form in the register file. We voted on whether to require 20 digits or 22; the vote was 10 for a 20 digit requirement to 2 for a 22 digit requirement.

Describing NaN behavior

In our review of the definition of NaNs, Hauser recapitulated concerns over where and how we should describe which operations propagate NaNs. We have, at various times, called these arithmetic operations or algebraic operations, or just included a list. Kahan suggested just including the list in the glossary until we have a better place for it. Zuras agreed.

Darcy recalled that a rationale document for NaN behavior was mentioned some months ago. Kahan replied that the document was in progress, and was currently 37 pages long.

Hauser objected that the section on NaNs is the right place for detailed list. A better way to structure things, he suggested, might be to specify the old operations and special case behavior in one place, and then separately specify new quiet operations. Schwarz agreed, but suggested that it should be taken offline until a concrete proposal was ready. Hauser said he was willing to make an organizational proposal, but that it would take a couple months.

We also briefly discussed NaNs when we came to the section on min and max. What is the right behavior for min and max with signaling NaNs? Should the sign of the NaN be considered? What about the possibility that a signaling NaN represents a pointer for missing data? Hauser and Thomas felt that including signaling NaN support for compatibility did not justify massive changes to support a minor user base. Hough responded that if we will not support these prototypical signaling NaN applications, he would prefer to get rid of signaling NaNs entirely and grandfather in existing implementations in other ways.

Is zero fish or fowl?

Kahan observed that in the past, many people have referred to zero as a normalized number. Therefore, he felt it important that we state explicitly, perhaps in a footnote, that zero is not a normal or subnormal number. Erle suggested we might include such text for infinity as well.

Decimal has many zero representations, but they all have value zero, and the value is what matters in our classification. Because of the redundancy in the decimal encoding, we must specify subnormals by the value, not the representation.

Sets of representable values

Hauser asked why we specified allowable exponents by minimum and maximum values and did not include the number of bits. Zuras replied that specifying the number of bits is tricky in decimal, where the combination field includes both exponent and significand information. Also, we have been trying to move from definitions in terms of formats to definitions in terms of values.

Hauser also asked whether we had a requirement for the relationship between the minimum and maximum exponents. Darcy replied that he had raised the same issue before, and might deal with it during his stint as editor. Such a requirement does exist in 854. Kahan noted that 854 provided a rationale for why the exponent range should be balanced; programmers might be annoyed if expressions of the form (modest value) / x frequently underflowed. He noted that the extended specification requires less care, since programmers must adopt a particular discipline to use extended effectively.

Kahan also noted that, since this the section on sets of values should describe values rather than representations, we would like to change from a digit-based description to something that specifies integers and ranges.

Decimal formats

Cowlishaw asked whether we should continue to use case to distinguish representations from values; Kahan replied that it was traditional. Someone noted that the digit labeling conventions are confusing: is g(4) the fourth most significant, least significant, leftmost, or rightmost bit? Also, there was a place where e0 appeared rather than e(0).

Someone suggested we make a table for combination fields. Erle asked if there was a general rationale for adopting text over tables; Hough replied that he thought text was more compact and comprehensible, but others might differ.

Delp noted that we are silent on the subject of redundant encodings; he thought we should say something about encodings that we will accept as valid, but will never produce. Zuras noted that we settled on using the formulas to give values for those bit patterns, even if they are redundant. Delp thought we should say explicitly at least that we always accept the redundant encodings. Kahan asked why we would not just make the extra encodings NaNs. Schwarz replied that, from a hardware perspective, it's easier to just decode those bit patterns as values; and Zuras pointed out that if we outlawed those patterns, we'd be making a new class of NaNs. Kahan stated that his concern was picking up values from memory when he shouldn't have; Bindel, Delp, Hauser, and Darcy all replied that outlawing those bit patterns would not greatly help to avoid problems with uninitialized or mis-initialized memory.

Temporary editor and scheduling

Joe Darcy will be the temporary editor for April and May. Because several committee members will be in Spain for the ARITH conference June 15-18, we decided not to meet in June. In April, we will discuss textual representations of special values and the behavior of min/max with signed zeros. We also decided to have a two-day meeting at the end of May to discuss decimal arithmetic. The two-day meeting is also to test Delp's assertion that we should consider meetings longer than half a day to make up for our slipping schedule.

The next three meetings will be:

754 | revision | FAQ | references