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
Xref: dummy dummy:1
X-OldUsenet-Modified: added Xref
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