Notes from Wednesday 8/18 draft review...
These are my notes from today's draft review. They are
incomplete as it was necessary for me to leave early (just as
the discussion began on inorder & modes). I hope you can get
those comments from someone else's notes.
Beyond that, most of the sub-committee's work will be presented
more fully in the general meeting tomorrow.
See you then,
The Wednesday 8/17/04 draft review meeting of the IEEE 754
revisions group was hosted by David Hough at 1:00 PM in the Moss
Beach Room in building 16 of the Sun facility in Menlo Park.
In attendence were:
David Hough Sun
Marc Dumas CNRS-INRA
Dan Zuras Chairman
Alex Liu Sun
Jim Thomas HP
Eric Schwartz IBM (phone)
Mike Cowlishaw IBM (phone)
Bob Davis IEEE
Then we started with the draft review.
Dave added the patent boiler plate with the blessing of our
The NaN text on page 20 was finally OK'ed.
Page 59, revised conformance predicates. OK'ed but Jim noted
that the ability to determine which types are supported is
still an open issue.
Page 60, "arithmetic" indicates (in purple at the moment) that
illegal declets are set to zero. We will map them to their
Page 61, elaborate logic for min & max. On seeing no mistakes,
we decided to accept this until we see the full context of
Dave's work in total ordering.
Similar text through page 63.
Page 78, section N defining the intent of the new level of
Page 79, N.x.1, paragraph 3, the table mentioned is the table on
operations in section 5. Dave will make it more clear.
N.x.1, paragraph 4, seems like an invalid operation but its not.
In general, Jim raised the issue of why some of the stuff was
here & not in the body of the standard. This raises the larger
issue of what should be described for only level 2 conformance &
what should be demanded of level 1 conformance (even if they
don't currently do it but if it would be easy to implement
without taking a performance hit).
Page 80, definition of the payload. Mike thought we decided
that the contents of N.x.5 should all go to purple so we'll do
that. Also, that invalidNaN() makes no sense in the current
On to Annex Z. So I spent a lot of time describing it.
Jim mentioned that I haven't said that one could implement only
one format & be OK. He also wondered how it would appear in a
language. Dave said that Fortran already does something like
this with REAL*N. I brought up the subtlty of the difference
between a generic routine & a collection of specific routines.
Joe Darcy said the "Fast & Efficient Binary to Decimal
Conversions" are not generic so I'll have to look into that.
Alex wondered if the notion of a "wire format" & data exchange
is part of our charter.
On to inorder (from inorder.pdf).