Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!charon!dik From: dik@cwi.nl (Dik T. Winter) Newsgroups: comp.arch Subject: Re: Killer Micro II Message-ID: <2034@charon.cwi.nl> Date: 29 Aug 90 23:58:30 GMT References: <2471@crdos1.crd.ge.COM> <1990Aug29.175933.28804@zoo.toronto.edu> Sender: news@cwi.nl Organization: CWI, Amsterdam Lines: 45 In article <1990Aug29.175933.28804@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > In article <2471@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > > I hear from the applications support people that few of our Cray users > >are doing 128 bit. It does get used, but more as a reflection of > >problems with the N.A. than because the input or output data are > >significant to that extent. > > I would suspect that the awful properties of Cray arithmetic might also > have something to do with an occasional need for 128 bits. Yes, they are awful. But their awfulness is at least well documented. (And if you look at Cray arithmetic as arithmetic with 46 bits plus noise in the remainder, it works out quite well.) I think Cray arithmetic is useable (some will disagree with me, notably Kahan). On the other hand DEC's D-float is extremely well behaved, but some very well conditioned problems can be solved using standard methods on the Cray, but not on the VAX. The reason: insufficient exponent range. But I digress. The reason some people use 128 bit floating point (96 bit mantissa on the Cray) is that they need it to get reasonable results. And this is independent of the precision of the input data. There are enough processes where the result to a large extent independent on the input data. In most cases the problem is 'close' to a singular problem, but it is so 'far away' that a loose perturbation of the inputs will not make it singular. And they do it even when 128 bit floating point is much more costly as 64 bit floating point. (What was it on the Cray? 10 times? 20 times? Something like that at least, it is in software.) Some years ago I was involved in a project to separate the 'smallest' 1 billion zeros of the Riemann zeta function (actually we overshot and got to 1.5 billion). Also here 128 bit floating point was regularly needed to get proper results, and this was based on a priory analysis. (This was done on a Cyber 205. Now, if you talk about sloppy arithmetic, here is your machine. What other machine has that a=b does not imply b=a? What other machine has vector instructions that can overflow if there are enough interrupts during execution? Disgressing again I think. But following another thread: timing. On that machine there is an instruction that can not be timed because the timer overflows. The instruction takes some 4 seconds to complete. Talking about CISC.) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl