- Dan Zuras (self)
- Eric Schwarz (IBM by phone)
- Peter Marksteir (HP)
- Jeff Kidder (Intel)
- Leonard Tsai (self)
- Jon Okada (HP)
- Bob Davis (Summit)
- Mike Cowlishaw (IBM)
- John Hauser (self)
- Jim Thomas (HP)
- Michael Parks (Sun)
- Ivan Godard (OOTBCOMP)
- Alex Liu (Sun)
- W. Kahan (UCB)
- David James (JGG)
- Joe Darcy (Sun)

Note taker: Jeff Kidder, Intel Corporation

[These are my raw notes. Please send any substantive corrections or omissions. Thanks.]

October meeting 10/16/2003:

- Draft review
- Expression evaluation
- Towers of precision / Trans / Formats
- State
- What are we going to do about NaNs (e.g., elimination of SNaNs)

- Definition of Quantum needed. Mike Cowlishaw to edit a definition.
- Section 3, Paragraph 1 revised.
- Section 3.0 background: Take out illustration and leave as table
- Discussion on the phrase "many of the axioms of real arithmetic, such as associatively of addition, do not hold for floating-point arithmetic". Proposed revision to "..., must be modified for floating-point arithmetic". [See Knuth Vol 2 on semi-numerical algorithms. Also Kahan, "Why we need a floating point standard"]
- May need to change where we move from one NaN to multiple NaNs. There is really no way without looking into the encoded bits whether two NaNs are the same or different.
- There is some concern about the exception with divide by zero. E.g., in "the extended reals" what is (1/1/-inf).
- The arrows in the table do not correspond to functions: the first is a many-to-one projection, the other two are one-to-many inverse function relations.
- Representable numbers:
- 3.3 Deleted second sentence which contributed more confusion than content.
- 4.1
Added "Round to Nearest Even" and "Round to Nearest Away from Zero".
The problem is that there are existing rounding implementations which
round any imprecise result to a even result, not just for ties. Could
use
- "Round to Nearest - Even"
- "Round to Nearest / Even"
- "Round to Nearest Ties to Even"
- "Round to Nearest TTE"
- "Round to Nearest, Ties to Even"
- "Round to Nearest, Ties Away from Zero"

- 5.5
- convertToIntegerValue (RINT) would raise precision
- roundToIntegerValue (NearbyINT) wound not raise inexact

- 5.8 Get exponent: What is the definition for decimal?
This function is used for very fast library for e.g., logb.
I.e., something like int(log2(x)).
In decimal we may also want info about the cohort member.
logb = floor(log_b(x))

Moved to drop getexponent and use quantum to fill the need. Argument against: provide a way to extract fields from the format in a platform specific way. They are available from nextafter. Could call it logquantum Removed getexponent

getMSBexp = The exponent of the most significant digit (also of a normalized number)

getULPExp = The exponent of the least digit -
5.12

EXPO(s,e,m) = e + 1 - p

There is a left adjusted exponent (e) and a right adjusted exponent (e+1-p) ("logquantum" or something less of a mouthful). E.g., 3 / 8 has a preferred EXPO of 0, but actual result EXPO of -3. Proposed name for EXPO: Integer Coefficient Exponent - Appendix 1
- 3 scaleb: Kahan requests help in working out if this can be implemented with two multiplies in decimal.
- 14: In binary this is bit equivalence except for NaN. In decimal, the are multiple infinities also. What should we do with the 24 redundant declets.

The Tower of Precision - higher accuracy, or larger values in a
standard way

Is there a standard problem to solve? Can we make sensible definitions.

What is the radix? 2 or 10

What is the precision?

What is the exponent range?

Some want to specify bit patterns.

[There was a discussion of the demand and plausibility of their use.]

David Baily's package supports unpredictable amounts of precision.
Example: Semetrical Level Index -- extreme example of diversity.
Dave will propose a paragraph on formats.

Down to 4 pages.

Do we want to introduce into the standard translation from DEC VAX FP
into 754.

A: Historical FP formats

B: Integer formats 10.1-10.3

C: Big vs Little endian

Do we want to describe historical FP? Cray / VAX / CVC / NEC / MS FP /
HP 3000

Shouldn't this just be published in the anals of computer history.
IEEE 754r should be complete in and of itself. What do we do with 1596?
We would prefer to see this historical info just available on the web,
or
just republish the spec.

There are algorithms which are reasonably fast in the nominal case which
do correctly rounded.
Java has math and strict-math libraries. If you want reproducible
versions, you use strict-math. They are defined procedurally.
There are two kinds of performance penalty:

One: Can you figure out if it is correctly rounded

Two: If it isn't, you have extra work to do (upsetting vector
computations)

Have considered "levels of accuracy". Can't specify meaningful way to
specify lesser accuracy in a testable way, and in a way that maintains
expected properties of the function (monotonicity, symmetry, ...). "Each
transcendental function costs somebody's lifetime to understand."

Committee opinion: It is too soon to do this.

Next time: Tue 11/11 & Wed 11/12

Tue

* Short Draft Review

* State

Wed

* Testing

Looking for a volunteer for a standard implementation

Looking for a test suite

[Or funding for graduate students to do the work...]

* What to do about NaNs

December: Wed 12/10 & Thurs 12/11

* Speaker on testing