Minutes from 754R meeting 15 November, 2001

Minutes from 754R meeting, 15 November 01

0. Attendance
1. Review of the agenda and minutes
2. Election of new chair
3. Draft review
4. Quad precision
5. Text representation for NaN and infinity
6. Schedule

Terse summary of action items / future agenda items:

 - Revision of the wording for the scope and purpose section
   (Bindel, Thomas)
 - Agenda item: Further discussion of rounding precisions (Thomas)
 - Agenda item: Further discussion of "tower of precisions" (Zuras);
     discussion of possible additional formats (e.g. 80-bit) to follow
 - Further revision of quad text (Hough)
 - Write-up of objections to Darcy's NaN significand proposal (Cowlishaw);
     further discussion of textual representations on list
 - Determination of how many people overseas are interested in conference
   call participation, and whether an earlier time would accomodate


0. Attendance

The tenth meeting of the 754R group was Thursday,
15 November at 1:00 PST at Network Appliance.
In attendance were:
  David Bindel
  Mike Cowlishaw
  Joe Darcy
  Bob Davis
  Dick Delp
  Eric Feng 
  David Hough
  Rick James
  William Kahan
  Richard Karpinski
  Plamen Koev
  Ren Cang Li
  Alex Liu
  Peter Markstein
  Mike Parks
  Eric Schwarz (via conference call)
  David Scott (via conference call)
  Jim Thomas
  Dan Zuras

1. Review of the agenda and minutes

A discussion of quad precision was added as an agenda item.

Joe Darcy noted in response to a comment from last meeting's
minutes that it is possible to convert floating point numbers
(except possibly NaNs) to bit-by-bit representations via stock
floating point operations.  More details are given in section 4
of technical report UCB//CSD-98-1009, "Writing robust IEEE 
recommended functions in '100 % Pure Java'(TM)," available at


2. Election of new chair

Bob Davis will be assuming the position of general chair of
the MSC group, and so has stepped down from the position of chair
of the 754R subgroup.

Dan Zuras was elected as the new chair of the committee, and
Alex Liu was elected vice-chair.  Since there were no other
contenders, the vote was done by acclamation.

3. Draft review

The current scheme for the draft is
  - approved additions are underlined and in black
  - approved deletions are struck out and in black
  - proposed additions are red
  - proposed deletions are green

3a. Addition of scope and purpose

Bindel:  The current text repeats the point that the standard
  can be implemented in hardware or software.  Could we remove
  the redundancy?
Thomas:  The current purpose seems focused on reproducible results.
  This seems narrower than we intended; efficient implementation,
  breadth of operations included, and convenience to the user are
  also important.

Hough:  The wording is carefully crafted right now -- we did
  argue over this for a while.  However, someone is invited to do
  a rewrite which integrates the purpose and scope with the foreword,
  and removes some of the wordiness.  (Jim Thomas and David Bindel
  were nominated to rewrite this text).

Davis:  We will have to write a modification to the work request
  stating that we're changing the scope and purpose.  Otherwise, the
  IEEE will throw the draft out.  It's not critical that we do this now,
  just that we tag it.
    Also, remember that our audience probably won't appreciate
  maximal terseness.

3b. Definitions

Definitions of "exception" and "trap" were added.  "Denormalized"
was replaced with subnormal.

Darcy:  Should we have a definition for denormalize (the verb)?
  (Hough agreed to add the definition of denormalize.)

Thomas: Would it be helpful to have a footnote indicating that "subnormal"
  was called "denormal" in 754?
  (The group made general sounds of agreement.)

3c. Rounding Precision

Hough: Don't care much for footnotes that are essentially rationale.
  Think it would be better to have an appendix with the change list
  from 754 and associated rationale.

There were several minutes of discussion regarding footnote 4:
  "Control of rounding precision is intended to allow systems 
   whose destinations are always double or extended to mimic, 
   in the absence of over/underflow, the precisions of systems 
   with single and double destinations.  An implementation
   should not provide operations that combine double or extended 
   operations to produce a single result, nor operations that 
   combine double extended operands to produce a double result, 
   with only one rounding."

Someone remembered that the rationale for this footnote related
to division.  When two numbers of the same precision are divided
and the result is stored in the same precision, the result will 
never be an exactly representable number + 1/2 bit.  Some hardware
designers exploit this fact.  When the destination register has
less precision than the operands, an exact 1/2 bit can occur.

Hough: This footnote was never normative.

Kahan: Rounding precision control would exist only on certain kinds
  of hardware, whose natural register destination was wider than the
  operands.  The RS/6000 was like this.  Single precision was mimiced
  by rounding results first to double and then back to single

     double intermediate := operation on single variables
     single result := round intermediate

  Since the precision of double was more than twice that of single,
  the final result in this sequence would be the same as if only one
  rounding (from the infinitely precise result to single precision)
  occurred.  The problem is that

    single := double result from double operands

  may give different results if the infinitely precise result is rounded
  once, directly to single precision, than if it is rounded twice.

Jim Thomas:  One of the problems when we tried to address precision
  control in C99 was
    1. It isn't required for all implementations, and
    2. It's vague -- there must be some way to control the rounding
       precision, but the details of the interface to that mechanism
       are not spelled out.

Others noted that the inclusion of quad precision affects the
language in this section.  That issue was discussed more later
in the meeting.

Question: Do we want to remove footnote 4 completely?

We decided to mark rounding precision for further discussion
(a future agenda item).  Jim Thomas volunteered to lead on that

3d. Signalling NaNs

The section on signalling NaNs now specifies that signaling NaNs
should be distinguished from quiet NaNs by the value of the most
significant bit of the fraction field (0 for signalling, 1 for quiet).
There were no objections to this text.

3e. General comments

Hough:  Not much that we did survived a second viewing, and some
  of these points look a little strange on this third viewing.

Bob Davis proposed a "trick" to reduce the substantial space
per page given to the copyright notice.  In four point font
at the bottom of each page will be a statement that this is
not an approved draft, and that there is applicable copyright
information on the first page.  He will take the heat if the
IEEE folks disagree.

4. Quad precision

David Hough first walked through proposed additions relating solely
to quad (and not involving combinations of formats).  Proposed additions
included text added to the scope and to section 3, and also a figure
illustrating the quad format.

There was some discussion about how to categorize formats.  The initial
categories of single/double and basic/extended don't cover quad well.
We are not defining quad extended (anyone who wants more than quad 
precision generally wants very high precision).  After some debate,
Kahan suggested that we say there are three basic formats and two
families of extended formats, and include text to explain that double
is a member of the single-extended family and quad is a member of 
the double-extended family.  The group present generally agreed that
this sounded like a reasonable way to present the formats.  David
Scott pointed out that this means that some occurrences of 
"single-extended" should be replaced by "a single-extended," and
likewise for "double-extended."

Kahan:  Quad is a type of double-extended format.  The initial definition
  of single and double had an oblication that wasn't attached to the
  extended formats: the representation had to be reproducible.

  Do we want to impose the obligation of fast support for quad on HW
  vendors?  We have to allow for the possibility that someone will get,
  for example, a 96 bit word that is nearly as fast as double.  Just
  want to be sure that other possibilities are not precluded.

  The main reason for including quad as a basic format is that, if we
  don't, some marketing department may decide to start calling a format
  like doubled-double "quad."

Schwarz:  The z900 does support quad in hardware (albeit somewhat more
  slowly than double).

Zuras:  What about adding the 80-bit double-extended to the list of
  standard formats?

But there are multiple 80-bit types (Intel and Motorola).

Hough (?):  We should include text describing the purpose of the
  extended formats.

A future agenda item was proposed: after we finish the discussion
  of the "tower of precision" that Dan Zuras has been working on,
  we should think about whether an 80-bit format should be
  included in the standard.

Discussion then turned to the impact of quad on the rounding precisions
section.  Jim Thomas pointed out that there may be systems that deliver
not to the widest supported precision (say quad), but do potentially
deliver a result (say from single precision operands) to a wider format
(double).  Kahan suggested we refer to the "widest precision supported
by hardware"; several people objected that such language contradicted
the statement that the standard could be implemented in any mix of
hardware and software.  Someone else suggested the notion of a "performance
preferred format."  David Hough pointed out that our goal is
to get results with a single rounding, and that we could separately
recommend a dynamic facility for precision control.

The x86 presents a problem: one can change precision, but not
exponent range.  Darcy mentioned that when it is important to 
get the reduced exponent range (as in Java) for reproducability,
there is a way to get around the x86 behavior by scaling operands 
so that the subnormal behavior matches what would occur with
a smaller exponent range.

David Scott asked whether the format table should be labeled
"memory format" rather than simply "format," since the register
representations might not be so simple.  Rick James suggested
that we call it an "interchange" format instead, but someone
objected that then we would have to discuss endian-ness.
We decided to leave that discussion for later (a future agenda

David Hough agreed to attempt to revise this section to address
the points raised in our discussion.

5. Text representation for NaN and infinity

Joe Darcy started the discussion of textual representation by
summarizing the current situation.  754 does not talk about
text representation of NaN and infinity; 854 does, but not
in an optimal way.  The issue is (potentially) complicated now
by internationalization: what text representations should we
use in a not-just-ASCII world?  Darcy proposed using

  INF or INFINITY to represent infinity, with an optional
    preceding sign
  SNAN, followed by an optional significand representation,
    for signalling NaNs
  QNAN or NAN, followed by an optional significand representation,
    for quiet NaNs

Conforming implementations could output a subset of the available
representations, but would be required to recognize any of the
representations as a valid input.

The first round of argument involved the character encoding.
Rick James suggested that we specify ASCII representations and
leave open the possibility of other representations.  Mike Cowlishaw
made a proposal much like the one Guy Steele made on the mailing list:
simply refer to the characters without referring to the specific

The second round of arguments involved the representation of
the NaN significand.  One piece of the argument involved the
purpose of NaN significand representations.  Jim Thomas asked
the purpose of textual representations: input? ASCII data exchange?
Dan Zuras observed that since NaN significand meaning is platform
dependent, exchange of the NaN significand across platforms
may not even be meaningful.  Joe Darcy commented that in any
case it is unclear what should be transferred: the significand
bit pattern or the (platform-dependent) significand semantics.
A second argument centered around the form of the significand
representation.  Darcy's original proposal was that the significand
be a paren-delimited platform-dependent string.  But what characters
can go in that string?  Guy Steele pointed out on the mailing list
that control characters should probably not go in the string; Mike
Cowlishaw observed that there might also be problems if Unicode 
characters with no ASCII equivalents were included in the significand 
string.  One suggestion was that we simply use a hex representation
of the significand value; this suggestion was neither generally
accepted nor generally rejected during the discussion.  Mike Cowlishaw
had several objections to the somewhat vague proposition, and agreed
to write down his objections for further future discussion.

Kahan brought up the question of what representation should
be used if a width-restricted output format is used.  Jim Thomas
pointed out that the problem holds for representing numbers as
well, and that C, at least, breaks the width restriction
if a too-narrow field is specified for a numeric value.

Someone noted that if we are to use these representations as a basis for 
interchange, we should make at least some of our recommendations

At several points, there was confusion about the topic of discussion 
(textual representation of NaN and infinity in decimal-binary 
conversion / program I/O) and textual representation of NaN and 
infinity in program text.  While we may recommend equivalent support
in languages, at least to the point where we could type NaN and 
infinity literals, that discussion

We finally tabled the textual representation discussion in order
to move on to final business.  More discussion was to be taken to
the list.

6. Schedule

The original proposed time for a ballot draft for semi-formal or formal
release was the end of 2001.  That seems unlikely at this point.
Bob Davis requested a rough guess of when we would have
a ballot draft, which we would vote on and expose as a national
or international draft.  After a ballot draft is available,
a balloting committee would be formed to pass judgement on the
draft; that would take roughly three months.  We agreed that 12/2002
sounded like a reasonable (if hopeful) guess at when we would be
ready to release an official draft, but none of us wanted to be held
to that date.

The proposed date and locations for upcoming meetings are:

  13 Dec, 10-3, Network Appliance, Craftsman room
  17 Jan or 24 Jan, Intel
  21 Feb, Network Appliance
  21 Mar, Network Appliance
  18 Apr, HP (?)
  23 May, Network Appliance

David Scott was to look into what January date would work
for scheduling a meeting at Intel.  December's meeting
is planned for 10:00-3:00.  The idea in moving the meetings
earlier is to accomodate participants from overseas interested
in attending via conference call.  We agreed to ask by e-mail
whether people overseas would be willing to participate if
the meetings were moved earlier.  If there are few responses
(there is at least one, since Mike Cowlishaw expressed interest
in remote attendence, with preference for an earlier hour PST),
we would move back to the 1:00-5:00 time slot.

754 | revision | FAQ | references