[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
754R decimal formats: letter from SHARE Secretary, response from Kahan
===========================================================================
Letter on behalf of SHARE
===========================================================================
To the Chairman and members of the IEEE 754 revision working group,
As you may know, SHARE is an independent computer user's group founded in
1955 which now has a membership of more than 2,000 organizations.
Collectively, these organizations -- and SHARE -- represent more than 20,000
individual computing specialists. Our constituency includes many of the top
international corporations (including the majority of the FORTUNE 500),
universities and colleges, municipal through federal government
organizations, and industry-leading consultants.
The SHARE organization wishes to commend those in the working group on their
ongoing development efforts in providing a revision to IEEE 754-1985 that
will include support for a decimal floating point data type and the rules
related to its use. The portability of data and reproducibility of results
for such data is and will continue to be of great interest to many of our
member installations.
However, we have recently become aware that certain issues that previously
appeared to be resolved (stabilized) are now being reopened with minimal or
no consensus that there is any defect in the current draft proposals that
needs modification. Most notably this applies to the requirement for and
the specification of a single hardware encoding for each decimal floating
point data size.
SHARE understands the need for a well defined specification whose data
storage and data manipulation can be implemented on many hardware platforms
and accessed through various software applications - and that this must be
demonstrably possible via efficient and portable methods (whether in
hardware or software).
SHARE has seen no evidence presented to the working group that this is not
possible with the hardware encoding specifications in the current draft and
suggests that unless a consensus that there is a problem to be fixed is
reached within the working group, that its resources and time should be
spent on:
-- correcting any identified (and commonly agreed upon) defects
-- clarifying ambiguities (if any) in the current specification
-- filling any omissions (that cannot be addressed in future
specifications).
In conclusion, SHARE sees no compelling reason to modify the hardware
encoding specifications in the current draft and does see a compelling
reason for the working group to progress the current specification to
completion and approval in the most timely manner possible. Please finish
the work you have begun so well and provide the world with an approved
revision as soon as possible.
James D. Michael
Secretary, SHARE, Inc.
e-mail: jim_michael@xxxxxxxxxxxxx
===========================================================================
Response to SHARE
===========================================================================
From: William Kahan [mailto:wkahan@xxxxxxxxxxxxxxxxx]
Sent: Thursday, July 14, 2005 9:46 AM
To: jim_michael@xxxxxxxxxxxxx
Subject: Re: SHARE Comments Regarding Revision to IEEE 754-1985
Ths responds to your letter sent recently, on 12 July 2005, to the
Chairman and members of the IEEE 754r revision working group, of
which I have been an active member. During the 1960s I was also an
activist in and contributor to SHARE, which I mention not just for
nostalgia's sake but to lend credence to the next sentence:
I share SHARE's concerns.
Some of my other concerns should be shared with SHARE in case they
will weigh upon the minds of at least some of SHARE's members. These
other concerns arise from the expectation that, if adopted widely,
the revised IEEE 754r arithmetic standard will outlast us all, for
good or for ill. Most concerns at issue fall under three headings:
DECIMAL How will a decimal arithmetic standard be used, and by whom?
~~~~~~~ This is the principal topic addressed hereunder.
EXCEPTIONS What facilities must hardware and programming languages
~~~~~~~~~~ offer to conscientious applications programmers who try to
produce robust and portable numerical software? Facilities currently
available, like Java's "try ... catch ... finally", intended for
operating systems' exceptions, are too heavy-handed for floating-point
exceptions and too error-prone generally. For alternatives see pp. 10
- 12 of <http://www.cs.berkeley.edu/%7Ewkahan/ARITH_17U.pdf>
<http://www.cs.berkeley.edu/~wkahan/ARITH_17U.pdf>, pp. 8 -
10 of .../Grail.pdf> and citations on p. 2 of .../ARITH_17.pdf> .
Relevant hereunder is a troublesome exception latent
in the decimal schemes currently under consideration
by the IEEE 754r committee but absent from all
other purely floating-point arithmetics. ~~~
DEBUGGING What facilities must hardware and programming languages
~~~~~~~~~ offer to conscientious applications programmers who try to
debug their handiwork? Their troubles become magnified when their work
incorporates subprograms obtained from others. Facilities currently
available in debuggers are practically incapable of debugging anomalies
due to roundoff, excited rarely by otherwise innocuous data, because
it is FUTILE to single-step through
programs intended to run at GIGAFLOPS.
For alternatives see
<http://www.cs.berkekey.edu/%7Ewkahan/Mind1ess.pdf>
<http://www.cs.berkekey.edu/~wkahan/Mind1ess.pdf>
and then $14 of .../Mindless.pdf> . ~
~
DISCLAIMER What I say here conveys my opinions and need not reflect
~~~~~~~~~~ the opinions of other participants in the work of the
IEEE 754r committee, which was not consulted during the preparation
of this letter. Moreover, my views may change. I shall gladly steal
better ideas from elsewhere and then boast about the theft, as is the
custom in Science and in Mathematics.
.......................................................................
The Case for Decimal Floating-Point Hardware
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Binary and decimal arithmetics differ only in their behavior when
rounded, starting with binary <--> decimal conversion. So far as I
know, almost all decimal arithmetic nowadays is performed in several
Fixed-Point formats (scaled integers whose scale factors get changed
relatively infrequently), not in Floating-Point, for commercial and
administrative purposes. These would not speed up very much if their
decimal arithmetic took no time at all. Yes, I know about examples
cited to show how enormously faster they would run if decimal were
built into hardware instead of simulated in software. All, so far as
I know, of these examples can be countered by the observation that
their decimal arithmetics achieved superfluous portability by resorting
to algorithms substantially sub-optimal for any particular commercially
significant platform. In other words, if your simulation of decimal
arithmetic is slow enough, it can make any application appear eligible
for an enormous speed-up if switched to fast arithmetic hardware.
I have not been convinced that speed alone justifies
building fast decimal floating-point hardware today.
I believe there is a better justification: Reliability.
Binary floating-point is noticeably better than decimal for error-
analysis so, as an error-analyst concerned with the reliability of
scientific, engineering, statistical, financial, economic and
medical computing, I should advocate binary for everyone. But decimal
floating-point is more humane than binary because everybody learns
about decimal in grade school, and that will never change. Attempts
to foist binary upon everybody almost always generate Errors Designed
Not To Be Found; see http://www.cs.berkeley.edu/~wkahan/ARITH_17.pdf
<http://www.cs.berkeley.edu/%7Ewkahan/ARITH_17.pdf>
and .../Mindless.pdf for a typical nasty example and its explanation
presented this summer. A similar example now about a dozen years old
was included in a presentation to IBM at Yorktown Heights about
half a dozen years ago: See pp. 12 - 24 of .../MktgMath.pdf .
A major decrease in avoidable silly errors can be achieved by letting
most (not all) scientists, engineers, ... and other computer users
perform most (not all) of their floating-point arithmetic in decimal;
therefore that is the way we must go. But we won't go that way unless
decimal floating-point is FAST, which implies that it must be built
into hardware, not merely simulated in software.
IBM now chooses to go that way. I applaud that choice although it
would have been better chosen over thirty years ago when I and several
IBMers at Yorktown Heights urged IBM to go that way. Back then
IBM was still the 800-pound gorilla of the computing industry. Now
the gorillas are Microsoft and Intel. How much do we accomplish by
promulgating an arithmetic standard that seems to favor the old gorilla
if the new gorillas and monkeys won't follow it?
Software vs. Hardware
~~~~~~~~~~~~~~~~~~~~~
On the path from where we are to where we must go, the new gorillas'
first steps will be software simulations of the decimal standard.
Simulations can too easily be fast enough for existing commercial and
administrative applications but too slow to attract new applications
first from the statistical community and then from the scientific and
engineering communities. These communities need arithmetic to be both
fast and cheap. "Cheap" has never been IBM's forte. Hardware gets
cheap enough for scientists to afford after it is produced in enormous
volume to satisfy initially the commercial and administrative markets,
and now the markets for entertainment, games and communication. If
none of these markets need cheap decimal hardware, it won't be built.
In short, the speed of software-simulated decimal floating-point will
matter no less than the speed of hardware. We should not jeopardize
that speed by specifying too tightly HOW numbers shall be encoded if
all we care about is WHICH numbers are encoded. Should proper care
of non-standard "declets" weigh upon every implementation? Must every
implementation preserve unnormalized numbers' leading zeros that could
be restored fast enough by auxiliary operations invoked only by those
applications that care about such arcane (to scientists and engineers)
things? Should a severe exception be signalled when a decimal result's
exponent differs from the "Preferred Exponent", defined in $5.12 of
the current draft, even if the result is exact? (If ignored, such an
event may force an unexpected rounding and consequent discrepancy later
when the cause, somewhat like a field overflow, can no longer be
found.)
I think questions like these await fully satisfactory answers. On
reflection, you may agree ...
"SHARE understands the need for a well defined specification whose data
storage and data manipulation can be implemented on many hardware
platforms and accessed through various software applications - and
that this must be demonstrably possible via efficient and portable
methods (whether in hardware or software).
SHARE has seen no evidence presented to the working group that this is
not possible with the hardware encoding specifications in the current
draft and suggests that unless a consensus that there is a problem to
be fixed is reached within the working group, that its resources and
time should be spent on: ...(better things) ... "
Maybe the evidence needed to change minds will be presented at today's
meeting. Absence of evidence is not enough for conviction. The 754r
committee needs a reason, preferably a good reason, for its every
decision. "No evidence that ... there is a problem" may imply only
that we all have not yet looked deeply enough. There is a viscosity in
the human mind limiting the speed of understanding. I had 25 years'
experience with all kinds of binary floating-point when IEEE 754 was
drafted in 1979. We have nowhere near that much experience with the
weird but tantalizing decimal hybrid-fixed/floating-point proposed in
the current draft of 754r.
We could pass the buck.
~~~~~~~~~~~~~~~~~~~~~~~
When the 754r committee was given its marching orders they were to
reconsider the IEEE 754 Standard for Binary Floating-Point and, if
possible, merge it with the IEEE 854 Standard for Decimal Floating-
Point. The present draft of 754r is upward compatible from 854 but
adds tricky features and constrains implementations severely. We could
abandon those features and constraints and still discharge our mandate,
and do it a lot sooner. I would rather persist with those features;
I believe they offer the best available way to make decimal floating-
point ubiquitous and hence enhance the reliability of floating-point
computation generally. Of course, reliability will be enhanced only
if we get all the details right. I hope we can do that soon since, at
my age, the only alternative to Soon is Never.
We may reach a decision sooner if we can answer several questions among
which are these:
What is today's practice of decimal arithmetic? How much of it is
likely to change under the impact of a decimal floating-point standard,
taking into account that almost all of it is fixed-point arithmetic?
What formats are in use today for large collections of decimal data?
When last I studied these questions three decades ago, most such data
was either BCD or a printable/displayable format analogous to today's
ASCII and Unicode. In any event, almost all of it was self-evident
in the sense that non-numerical characters separated strings of digits
conveying numerical data according to one of a few familiar encodings.
Many of these collections packed their BCD data rather more densely
than we could pack it if we had to choose either a 4-byte or an 8-byte
"standard" decimal word for every datum. Most programs managing that
data were described by their users as "impossible to change" although
actually programs were being modified and even rewritten continually.
How likely are those collections to be converted to a standard format
like the one in the current 754r draft? Will Oracle ever change?
Suppose 754r specified only the sets of values, one set for each of
the three decimal formats (4-byte, 8-byte and 16-byte), leaving
the choice of encoding to the architects of the processor. Presumably
two processors that can run each other's binary object code modules
would use the same encodings. Processors that cannot run each other's
binaries would be free to choose different encodings. This would force
different computers to exchange decimal data in ASCII or Unicode or
possibly BCD. How bad would this kind of "standardization" be? How
would it compare with today's practice?
We don't have all the questions, much less all the answers. SHARE's
members can help by sending us in 754r some of each. Send e-mail
to the chairman at r754@xxxxxxxxxxxxxx .
......................................................................
Mathematical decisions are not the kind we should make by political
processes like voting. Otherwise the number pi would be 3 in some
jurisdictions and 22/7 in others. The voting process for 754r
expects negative votes to be accompanied by a reason and preferably by
a constructive suggestion of an alternative too. Discussions have to
illuminate and educate rather than just advocate. Yes, that looks at
first like a prescription for interminable discussions, but it isn't.
You see, floating-point is an extremely dull subject when it is done
right. If you believe, as I do, that it can be done right, then the
time must come when nothing interesting remains to be said. Soon, I
hope. Every decision has to have a reason, preferably a good reason,
so that the final decision will be better than a typical "Business
Decision" since we will all be stuck with it for a very long time.
Prof. W. Kahan
Elect. Eng. & Computer Science Dept. #1776
Soda Hall
University of California
Berkeley CA 94720-1776
<mailto:wkahan@xxxxxxxxxxxxxxxxx>
<wkahan@xxxxxxxxxxxxxxxxx>
===========================================================================
Response from SHARE
===========================================================================
Subject: RE: SHARE Comments Regarding Revision to IEEE 754-1985
Date: Thu, 14 Jul 2005 11:09:45 -0700
From: Jim Michael <jim_michael@xxxxxxxxxxxxx>
Organization: California State University, Fresno
Dr. Kahan,
Thank you for your letter with regard to this issue. I appreciate the time
you've taken to share with us your hopes for, and concerns regarding, the
current draft standard. I especially appreciate the effort you've made to
help us understand the basis for your comments.
I also appreciate your mention of your involvement at SHARE in the 1960s.
I'm sure you'll be glad to hear that the organization is still strong and
vital as we celebrate our 50th anniversary this year at our conference in
Boston, August 21-26.
I hope that the working group's meetings this week are going well and I look
forward to hearing more about the progress you are making in your work
together. I'm sure that the SHARE Board of Directors will be interested to
hear about the status of your work when they meet in Boston.
Best wishes,
Jim Michael
--
James D. Michael
Secretary, SHARE, Incorporated
e-mail: jim_michael@xxxxxxxxxxxxx
"Never doubt that a small group of thoughtful, committed people can change
the world. Indeed it is the only thing that ever has."
Margaret Mead