5th operation?

[uunet!cwi.nl!Dik.Winter]

(I did intend to let this go only to the list, but when I tried to edit
the header from SunOS's /usr/ucb/mail I refrained.)

 > "If you don't care about the error then you don't care about the answer."

 > That this is the underlying problem in the bank example can be seen by 
 > considering the consequences of any uncertainty in the summands.
But with bank-examples the input is *always* exact, the result is properly
rouded up or truncated (depending on whether it is in the interest of the
bank to round up or down), but there are exact points where rounding errors
should occur, and it is even given which way rounding errors should occur.
The main conclusion is that banks should *not* use floating-point (contrary
to popular believe) because it is in a sense unpredictable.

 > One correctly-rounded dot product won't help with that.   However, one
 > correctly-rounded INTERVAL dot product would demonstrate the error inherent
 > in the computed result.
I agree that one correctly-rounded dot product will not help.

 > But even considering only exact input data,
 > there are other ways of estimating the same error that may be more
 > economical, such as keeping track of the largest magnitude intermediate result.
In the banking example this will of course not help.  The are not interested
in the fact that the net result has an estimated error of $34,000; they want
to know where that money has gone, and to whom (and they will not yell if it
is their profit) :-).  Numerical mathematics is of course a completely
different matter.

 > For this purpose, a machine operation that implemented, or assisted in
 > fast implementation, of 
 > 	z = |x| + |y|
 > would help, provided languages provided easy access.    Such an operation 
 > exists, for instance, in the Weitek 1164/5 chips used in the Sun-3
 > floating-point accelerator and the Sun-4/1x0 and 4/2x0 systems, but there's
 > no hardware access to it from the Sun-4's FP controller chip
 > and no language support in the FPA.
It was also in the late Cyber 205, also unsupported in HLL's.  There must be
a reason.

 > The crux of the argument about correctly-rounded dot products is whether
 > they provide or could provide
 > an economical solution to the problem of estimating the effects
 > of various kinds of errors, compared to other methods that have been or
 > might be implemented.
Banks are not interested in error estimates, they want exact figures.

 >                         Arguments on both sides are somewhat impeded by
 > lack of best possible hardware implementations and inadequate access from
 > standard programming languages.   It's my belief that extending GCC and
 > when ready, GNU Fortran, is the best provide a widely-available solution
 > to the latter problem .
I do not know.  Karlsruhe has made many attempts, starting with Fortran-J,
continued with Pascal-SC, and also some later efforts.  At some stage there
was an IBM with hardware support.  It just did not do it.  Support is
expensive, especially with the current pipe-lined processors.  You need
to maintain a register that is extremely wide.  But you need also the
ability to store that register in user space and retrieve from it (in the
event that dot-products are broken in parts for some reason).  To be
reasonably able to retrieve information about such huge cancellation a
more sensible approach would be to extend IEEE with a flag like
huge-cancellation-did-occur.  The inexact flag does not make it.
What still remains is of course how to define huge.

All of course IMHO.

dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dikacwi.nl