Minutes from 754R meeting 15 November, 2001
Minutes from 754R meeting, 15 November 01
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
Terse summary of action items / future agenda items:
- Revision of the wording for the scope and purpose section
- 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
The tenth meeting of the 754R group was Thursday,
15 November at 1:00 PST at Network Appliance.
In attendance were:
Ren Cang Li
Eric Schwarz (via conference call)
David Scott (via conference call)
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
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
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
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
But there are multiple 80-bit types (Intel and Motorola).
Hough (?): We should include text describing the purpose of the
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
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 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.