IEEE 754R minutes from 13 and 14 August, 2003

Note taker: Mike Cowlishaw, IBM

I haven't been able to find any minutes for the August 2003 meeting, so here are my notes from that meeting (mostly covering the draft review). These capture the decisions taken at the meeting.

Mike Cowlishaw


Draft Review

This was a two-day meeting, the first day being draft review and the second scheduled for discussion. In practice, it was a 1.5 day draft review followed by a presentation (by Professor Kahan) on Exceptions.

The draft reviewed is dated 2003 August 12 10:20, and was at:

http://www.jddarcy.org/drafts/754r.pdf

The first day confirmed many of the details and editorial changes in that draft, and deferred substantive items to the larger meeting the following day. The questions discussed and agreed then were:

3.1 - 3.3 (Binary and Decimal Formats)

move all three sections to black, indicating they are accepted text. Further changes will be editorial only, to align terminology with the new background model proposed in 3.0 (which remains red for the present).

4 (Rounding)

4.1 - 'Round to nearest' will be renamed 'Round to nearest, ties to even' for clarity.

4.x - A new rounding mode 'Round to nearest, ties away from zero' will be added (required for decimal, optional for binary)

4.2 - There was no agreement on adding any additional rounding modes to the Standard.

5.11 (Decimal-specific operations)

checkquantum -- renamed to samequantum

requantize -- renamed to quantize

quantize -- arguments will take the same form as samequantum (i.e., the second argument will be a decimal number, forming a 'pattern'; the result is then the first argument, quantized to have the same exponent as the second).

5.12 Decimal exponent calculation

The table of preferred exponents will be moved to black, except for the two rows with '?' (conversions).

The section will be clarified to indicate that the preferred exponent rules are only applied if the result is exact. Rounded normal results, therefore, will always have a full-precision significand.

6.2 Operations with NaNs

A long discussion came to no agreement on a form for canonical NaN; it was felt that none should be defined because specifying a canonical NaN would discourage implementers from including diagnostic information. However, there was some consensus that if no diagnostic information were available then 'all undefined bits set to zero' would be useful as they would indicate the lack of diagnostic information (and this is also a valid bit pattern in the decimal formats).

There was also no agreement on specifying NaN propagation (e.g., after an Add of two NaNs, which NaN is returned as the result?), or on any rules for the sign of a NaN.

There was a suggestion that 'use larger coefficient' might be a good propagation rule, especially if 'coefficient=0' indicates no diagnostic information, however existing hardware (binary) uses a variety of different rules.

Exceptions

The second half of the second day was a presentation by Professor Kahan on the background and requirements for Exception handling. This proved to be controversial; by the end of the meeting the committee was still on chart 4.

754 | revision | FAQ | references