🚀 go-pugleaf

In article <KHB.91Jun11185538@chiba.Eng.Sun.COM>, khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes:
 
> In article <9106120054.AA19903@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
 
>    instructions into the IEEE standard and they have been implemented
>    in hardware in many machines.  Interval arithmetic still hasn't
>    gotten off the ground.  How long are we expected to wait until
>    concluding it's not going to fly.
 
> Until vendors (other than apple and sun) provide hooks that people can
> actually use. Had such hooks been part of _any_ language standard, I
> suspect folks with such interests would have merrily coded up systems.
 
>        3. The real problem with interval arithmetic is not that it's
>    slow but that on real applications its error estimates are gener-
>    ally so pessimistic as to be useless.
 
> At last, something we agree on! But I confess that I have not used it
> extensively, so I am prepared to believe that it may have utility I am
> not personally cognizant of. Interval techniques will have to be
> deployed in large quantities before it can be counted out of the
> running, IMHO.

Interval techniques will often be needed when extreme accuracy is needed. 
But in these case, it will probably be necessary to use multiple precision
anyway.  There are cheaper ways to analyze errors in most situations than
interval arithmetic, but they involve using various precisions.  In some
cases, a very good estimate can even be made in advance of any computation.

I suggest that someone who thinks interval arithmetic is that great try it
on some such task as computing a convolution using the FFT.  There are many
reasonable examples where one would even throw out the idea of using the
faster FFT, even with multiprecision, in favor of methods not so prone to
error.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)