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

IEEE 754R Meeting April 15, 2004 Raw Minutes

ATTENDEES: Dan Zuras, Matthew Applegate, Eric Schwarz, Mike Cowlishaw,
Michael Parks, Dick Delp, Peter Markstein, David Hough, Jim Thomas, Jeff
Kidder, Jon Okada, Prof. Kahan, Jason Reidy, John Hauser, Joe Darcy

DRAFT REVIEW in morning 10 - 11:40am - Jeff Kidder and David Hough took


Only resolutions on NaNs
      1) we will not require sign bit propagation on NaN
      2) must propagate one of the input QNaNs (no commutativity)
Comebacks for Jeff Kidder:
      1) need conversion proposal
      2) need to look SNAN and QNaN encodings
      3) need language for integer payloads of instruction for NaNs

Also I would like thank ARITHMATICA for hosting the meeting.  It was an
excellent facility for having a meeting.  Thanks, Matthew and Clem and the
rest of Arithmatica.

DETAILS OF MEETING:  (probably more than most people care for, but just in
case details are needed later)

discussion on 1xxx being SNaN,  this causes problems for quieting, causes
01xxx to be the quieted sNaN
copyQNaN(x) argued on the data type that should be returned,
predicates (sameNaN(x,y)) - question should payload for comparison include
bit separating sNaN from qNaN
Rules of QNaN propagation  Proposal A, silent sign bit,  B - sign bit is
Quieting an SNaN, - do we want a separate pattern for SNaN vs. a quieted
SNaN vs. a original QNaN
      suggested a pattern to indicate no information in NaN payload ...
754 only specifies "should" propagate one of the input QNaNs
Propagating NaNs must be done at high speed, so easy hardware algorithms
are needed
      if complex, then will be done in software which delays execution
Kahan would like propagation of one of the input NaNs, and would prefer
payload to be instruction address
      then if he fixes that one, it should not appear again.
Darcy would like reproducibility of propagation of NaNs, for code debug on
different platforms, and testing
Kahan asked what part to preserve on conversion from Double to Single
      Kidder suggested preserving high bits
      Schwarz argued for low bits for decimal, and if instruction address
is encoded
      BFP wants to preserve left and DFP wants to preserve right
Further discussion on payload for CopyQNaN
Should the all ones pattern be an SNaN?  Hough argued for it ,
Schwarz argued all zeros better if this were a significant argument

Hough argued for SNaN to be eliminated
      implementation defined signaling behavior, since can't get traps

Zuras -   Proposal to just propagate one of the input QNaNs rather than
strive for Commutativity
MIPS and HP-PA return canonical NaN

microprocessor standards committee wants all normative text in the main
body of text and not an appendix (prefer annex),

Schwarz suggested encoding NaNs with the first bit of fraction equal to
one, Kidder pointed out this produces illegal representations

Hough's proposal of "should" have a trapping NaN with an enablement bit
Kidder wanted to know pattern and what the encoding is, but Hough didn't
want it specified

Zuras asked "will we have traps"?
      Hauser said there should a terminating behavior
      Hough - No, because non-portability of the environment

Darcy - it is not our job to find uninitialized data. There are better
mechanisms available.

Zuras proposes - there is set of NaNs called QNaNs and an undefined section

Hough and Darcy want to get rid of SNaNs because not worth their weight
Hauser - should be compatible with old standard except if there is no
audience for function
      wants to drop SNaN completely
just SNaN part of invalid exception would be removed.

Hauser - Does any language support SNaN?
      C++ was suppose to but definition conflicts with it.
      Individual user created own language.

Steve Walther and  Bob Fraley of HP Deer Creek Rd insisted on SNaNs in 754.

Kidder suggested stating there are zero or more SNaNs.

Kahan said there was an implementation on an IBM PC in assembler written
using SNaNs for statistical analysis, argued not to remove them

Signalling NaNs do not have to trap to comply with 754
Hough - symbolic links to history (Mary Payne's example) more important
than uninitialized data

Public Comment -
      getting a voting list, yeh or nay and why not
      decided to review nay arguments as a committee

discussed whether SNaNs should exist at all
      Kidder proposed no

argued again whether SNaNs should be used for unintialized data
      Reidy - problem applies to more than floating point and should be
solved in general way, Purify tools
      Kahan - Acromen function example of program with difficult

Straw vote - Elimination of SNaNs for Upward Conformance - Level 2
            8 for - 3 against - 3 abstain
      No rational for arguing either way, could easily be reversed
      Traps have already been eliminated

Kahan argued for help in debugging programs

Discussion went on to discuss use of Inexact Flag
      Kahan "most people who knew how to use it (Inexact Flag) have died."
:-(  joke
      tricks in using inexact flag, advantage in solving cubic equation,

      inexact doesn't require much hardware and doesn't penalize execution
time except for divide

SNaN cost is mainly in terms of complexity of the standard
      by making optional it may make language standards simpler

Markstein argued that we should specify that copying does not set off SNaNs

Agreed there are nuisance cases

Schwarz posed question of whether Decimal and Binary should have separate
flags and rounding modes?
Hauser and Kahan agreed that flags should probably only have one set
Kahan stated that rounding modes may want to be separate

Straw Pole on whether signalling NaNs are optional in Level 1 and 2?
      6 for - 4 against  - 5 abstain

Next meeting May 12-13 Intel, Jeff Kidder


Systems and Technology Group
(845) 435-6413  /   T/L 295-6413

754 | revision | FAQ | references | list archive