Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: IEEE arithmetic (Goldberg paper) Summary: Problems with interval arithmetic Message-ID: <13450@mentor.cc.purdue.edu> Date: 12 Jun 91 13:12:01 GMT Article-I.D.: mentor.13450 References: <9106120054.AA19903@ucbvax.Berkeley.EDU> Sender: news@mentor.cc.purdue.edu Lines: 38 In article , 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)