IEEE 754R minutes from December 17, 2002

Attendance and minutes review

Because of a late posting, the minutes of the November meeting were neither approved nor disapproved. Delp was appointed to record the minutes of this session.

Future meeting schedule

The schedule of meetings for early 2003 was announced and agreed to:

DateLocationHost
January 23Sun, Menlo ParkHough
February 20Intel, Santa ClaraScott
March 20H-P, Palo AltoMarkstein
April 17H-P, CupertinoThomas

Decimal subcommittee note

Concerning the report of the Decimal Arithmetic Subgroup, Zuras reported that an impasse on the issue of Normalized vs. Unnormalized had been partially resolved by compromise: the encoding format advocated by the Unnormalized faction was provisionally adopted; the arithmetic advocated by the Normalized faction was deferred. Details of the encoding format are available at http://www2.hursley.ibm.com/decimal/decarith.html. Professor Kahan forecast that in the relatively distant future, the continuing decline in the cost of processors and of memory would result (in applications intended for human interaction) in the displacement of substantially all binary floating-point arithmetic by decimal. Zuras remarked that our subcommittee would likely have to address issues concerning any revision to or compatibility with IEEE 1596.5 (data interchange).

Collishaw then made a presentation of details of the recommendations of the Decimal Arithmetic Subgroup. See http://www2.hursley.ibm.com/decimal/decarith.html.

Draft review

Hough reviewed the Draft Document, including revisions agreed to last meeting.

min and max

A discussion of the max/min functions ensued. Moved by Hough; seconded by Zuras: That the names "max" and "min" should be adopted for these functions by 754 in the reports of this subcommittee, in spite of the fact that not all languages spell the names of the functions in the same way. Adopted by voice vote.

There was general agreement that both of the following properties are desirable:

  1. The function should be symmetric: that is, its result should be independent of the ordering of its operands.
  2. When one operand is a NaN, the other operand should be returned. However, it was observed that this could cause a sort function to fail, or at least produce surprising results, when NaN's are included in the arguments, and that this behavior would differ from a sort function using the customary comparison predicate instead. So this issue may be resurrected. Kahan suggested consideration of a "lexicographic min/max", which would result in a sort operation producing a result - in the case where the comparison field contains both finite and NaN entities - in the desirable situation in which no Nan element is sorted between finite elements.

Also, the issue of the desired result when both arguments are zeroes was discussed. For the case where the zeroes are of opposite sign, both "return +0" and "return the right operand (violating symmetry)" were discussed. For the case where both zeroes are negative, both return -0 (one of the operands) and return +0 (by analogy with the +0 returned by the subtraction of equal negative numbers). Thomas and Darcy were asked to investigate the matter further and report at the January meeting.

Discussion of testing

A discussion of testing floating-point implementations -- especially hardware -- followed. Both black-box tests and architect-specific tests were alluded to. The problems in testing hardware items wherever unspecified or implementation-dependent results are present were briefly mentioned as being of serious concern to several members.

754 | revision | FAQ | references