[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: IEEE 754R meeting notes for 02/18/04 & 2/19/04



Here are Jon's notes from the last IEEE 754R meeting of Wednesday,
February
18, 2004.  My notes for the Thursday
(02/19/04) meeting are bellow.


IEEE 754R minutes from 18 February, 2004

o  754R NaNs

o  Future direction for 754R


ATTENDANCE
----------
o  Dan Zuras, self
o  Peter Markstein, HP
o  David Hough, Sun
o  Dick Delp, self
o  Alex Liu, Sun
o  Mike Cowlishaw, IBM
o  Jim Thomas, HP
o  Jon Okada, HP
o  Joe Darcy, Sun
o  Ivan Godard, OOTBC
o  Jeff Kidder, Intel
o  Eric Schwarz, IBM (phone)
o  Leonard Tsai, self (phone)

Note taker:  Jon Okada

---------
754R NaNs
---------

The following is a brief summary of Jeff Kidder's presentation of NaN
issues and his recommendations for NaN behavior under IEEE 754R.

Under IEEE 754-1985 the "level 4" (bit-level) NaN behavior is not fully
defined, leading to different implementations which impair both
portability and the usefulness of NaNs to programmers.  If NaN behavior
were fully defined, to include the specific quiet NaNs produced by
various invalid arithmetic operations and if quiet NaN source operands
propagate by somehow preserving the information encoded in their
significand bit patterns, then NaNs could provide some diagnostic
information regarding the history of invalid floating-point
calculations.

In a similar vein, fully supported signaling NaNs (SNaNs) in conjunction
with the invalid trap handler or special quieting behavior could be used
to detect references to uninitialized memory, to provide pointers to
special case data, or to represent missing data for statistical
operations.

Issues discussed were various schemes for NaN propagation, implications
for floating-point decimal NaNs, and the benefits of various proposals
versus their costs in terms of implementation and compatibility with
IEEE 754-1985.

Jeff recommended two plans for NaNs, one from each extremity of the
usability/complexity spectrum.  Under the more aggressive plan, the
result of an operation with multiple quiet NaN source operands would be
a quiet NaN with significand being the bitwise OR (for binary FP) of the
significands of the NaN sources.  For decimal NaN operands, a similar
information-preserving and commutative behavior must be specified.  NaNs
resulting from the various invalid operations would be fully specified
with presumably unique significand encodings.  SNaNs would be supported
with their quieting behavior fully specified.  Jeff stressed the need
for sample code which would illustrate and justify the usefulness of
both quiet and signaling NaNs under this scheme.

Under the second recommended plan, NaN behavior would be vastly
simplified but incompatible with IEEE 754-1985.  Any (quiet) NaN input
would produce a canonical NaN output.  Signaling NaNs are eliminated
altogether under this plan.


--------------------------
Future direction for 754R
--------------------------

The remainder of the meeting was devoted to discussion on the future
direction of committee efforts.  The temptation to mandate extensive,
comprehensive, and detailed changes to the standard (the "clean slate"
approach) must be tempered by considerations of legacy and the need to
achieve timely consensus within the committee and subsequent acceptance
by the user community.

Dan suggested that the committee take the clean slate approach and focus
on a new and better standard which would be of greater utility to
programmers.  He also stated that there is no hard deadline for the
completion of the revised specification.

Ivan noted that many of the new features under consideration, such as
alternative exception handling, are inaccessible to programmers unless
the standard addresses language binding of certain FP arithmetic
features and behaviors.

David pointed out that the only substantive changes agreed upon thus far
are the following extensions to 754-1985:  quad format, fma, min, and
max functions, and the detailed decimal specification.  He noted that
based upon past history, timely agreement on more controversial issues
appears unlikely.  He thus proposed that the IEEE 754-1985 standard be
supplemented by two appendixes containing the agreed-upon extensions:
    Appendix B (binary) - quad format, fma, min, max
    Appendix D (decimal) - complete decimal specification
No further changes would be accepted without a 2/3 majority vote of the
committee.

In the ensuing discussion, the following points were raised:

Joe suggested that the details of the decimal specification belong in
the main body of the standard, lest they be overlooked by appearing only
in an appendix.

Mike stated that the current revised draft is superior to 754-1985 in
its organization, consistency, and clarity.  In the same vein, Joe
stressed the importance of the section 3.0 description of the
multi-level floating-point model to programmers.

Jim proposed guidelines for completion of the committee's work:
    1.  Do no harm (don't undermine the benefits of 754-1985
        without compelling reasons).
    2.  Complete the standardization of FP decimal.
    3.  Complete the standardization of non-controversial
new
features:  decimal FP, quad format, fma, min, max.
    4.  Address other pending issues as time permits.

A straw poll was taken on David's proposal with the following result (12
committee members voting):  5 for and 7 against.  Several members on
either side stated that their preferences were not absolute.

Since the majority of the committee favored the current revised draft
over that of 754-1985, the following plan was proposed:  the main body
of the revised draft is to be carefully checked and limited to features
which are compatible with, or compatible extensions of, the existing
standard.  Thus, features such as the FP decimal specification, binary
quad format, and min, max, and fma functionality, would appear in the
main body of the revised draft.  In addition and time permitting,
specifications for language bindings and non-compatible functionality
are to be relegated to the following appendixes:

    Appendix L:  Language bindings required of conforming
        implementations (to include programming environments)
        which allow access to certain important features or
        functionality.

    Appendix C:  Recommended features which are incompatible
        with IEEE 754-1985 (e.g., elimination of SNaNs).

The Thursday meeting will be devoted to discussion of this latest plan
of action.

IEEE 754R minutes from 19 February, 2004

o

o


ATTENDANCE
----------
o  (I don't seem to have the sheet)

Note taker:  Jeff Kidder

---------
SNaNs
---------
Many of the problems that SNaNs are proposed to solve are not unique to
FP: initializing memory, overloading, missing data, etc. There are other
software techniques to address each of these.
However, eliminating SNaNs entirely would break compatibility with 754
where at least one is required.
There was some discussion of having a single canonical SNaN with a bit
pattern of all 1.
[note: see the "Appendix C" discussion]


---------
Proposal
---------
There was a proposal for the direction of draft:
Continue from the current draft body (which started
from 754 with changes for binary and the addition
of decimal), add an "Appendix C" to capture non-upward performance
compatible features with the goal of portable (level 4) behavior.,
and add an "Appendix L" to capture language considerations. Any
material appropriate for C or L will be moved from the body of the
draft.
Vote: Yea-10, No-1, Abs-1

Professor Kahan suggested we explain the purpose of the extended
formats.

Mike took an action item to propose how to move the cohorts treatment to
later in the document. 3.3 should have the fractional form but no
cohorts.

---------
Traps
---------
Need to specify what we want to accomplish for the user.
Say what a trap handler shouldn't do.
Services: masked; mask w/ inspection points of "flags"; masked state
safe; abandon if ...<some condition> / abandon by inspection point;
counting mode; pre substitution

---------
Proposal
---------
We should have "concurrency" issues section; have appendix L section to
address alternate exception handling; and should supplant the section on
traps with what we do want to say.
Vote: Yea-9,  No-0, Abs-4

---------
Next Meeting
---------
March 17-18     Sun 1-5
April 14-15 IBM or Arithmetica (might just be April 15 from 10-5)
May   12-13 Intel SC-12

754 | revision | FAQ | references | list archive