[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
IEEE754R11
David Hough wrote on 21 June 2007:
The time has come for decimal to resume its historical role as the
default floating-point radix
for most computations of most users, and 754R recognizes this by
encompassing decimal.
I fully support a move toward use of the decimal number system on
computers. It certainly
would eliminate many difficulties and unnecessary error sources in
computations.
In the same mail follows:
Reproducibility
So 754R has to come to terms with what will eventually become the
default requirement as
surely as decimal radix - namely floating-point results reproducible
on all implementations
of the same language. And just as 754R also continues to cater to
the
small but vital minority
willing to pay the price to reap the rewards of binary radix, it
must
also cater to that minority
by providing a way for specifying where "different but equally good"
results are allowable
for better performance on specific systems, for persons who can
accurately ascertain whether
"different is equally good".
An example of different but equally good:
s = x + y + z
where
x = 2**N
y = 1
z = -(2**N)
In the absence of roundoff there is no mathematical difference
between
evaluating s as
(x+y)+z or x+(y+z) or (x+z)+y ; nor is there any difference in a
typical error bound on the
computed answer, which will depend on the number of rounded
additions
and the magnitude
of the largest addend. But when N is much bigger than the precision
P
of the variables, then
(x+y) rounds to x, and (y+z) rounds to z, and the rounded sum of
(x+y)+z or x+(y+z) will be
0, while the rounded sum of (x+z)+y will be 1 exactly. If either x
or
z is not regarded as
exact but as possibly contaminated by roundoff and thus at least
uncertain by at least a half
ulp 2**(N-P-1), then that uncertainty swamps the difference between
the computed sums 0
and 1. But to recognize that requires some notion of error analysis,
while anybody can tell
the difference between 0 and 1. Fixing the order of evaluation of
x+y+z doesn't eliminate the
need for error analysis but widens the applicability of error
analyses
that are made, because
they don't need to be repeated (or the programs debugged) if the
results are the same.
The goal of 754R's reproducibility requirement is to provide a way
to
remove the
gratuitous variation added by programming environments when it costs
more than it
benefits. The primary beneficiaries of reproducibility features are
end user programmers
and ISV programmers who have been under-represented in the 754R meetings.
My COMMENT on this:
If the numbers in this example are of dollars I think most of us would
accept 0 instead of 1,
if this occurs only once. But if the 1 is replaced by 8192, I wonder
how many of us would
accept 0 as â??different but equally goodâ?? to 8192.
Not the best education in error analysis can help to foresee whether a
situation similar to the
example appears in a program that performs 10^15 floating-point
operations a second.
The only true interpretation of the different results is: 1 and 8192
are correct while 0 is wrong.
This is much more user-friendly.
I think that two diffenrent things are conflated in the discussion of
this simple example:
a) errors in the data that occur during a computation and
b) errors in the arithmetic.
a) is an unavoidable source of errors. Of course, the data are
frequently contaminated by
roundoff. But an error in the data does not justify error in the
arithmetic. The vendor is
responsible for the quality of the arithmetic. To be as accurate as
possible is essential.
Sloppy arithmetic prevents users from solving problems correctly when
the data are exact.
Compound arithmetic operations like â??accumulateâ?? (continued addition)
and â??multiply and
accumulateâ?? are common instructions on all vector processors. By
pipelining they greatly
speed up the computation. Compilers help to detect them in a
program. Within a certain
exponent range (double precision) these instructions can easily be
executed exactly.
This eliminates many difficulties and unnecessary error sources in
computations and so
must be implemented on future computers. 754R should require this from
all future processors.
For implementation details I refer to my upcoming book. It is entitled:
Computer Arithmetic and Validity â?? Theory, Implementation and Applications.
Ulrich Kulisch 27 June 2007
--
*************************************************************************************
Ulrich Kulisch
Institut für Angewandte Mathematik
Universität Karlsruhe
D-76128 Karlsruhe, Germany
Tel.: (+49) 721 608 2680 oder (+49) 721 608 4202
*************************************************************************************