Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!sri-spam!nike!cit-vax!ll-xn!adelie!axiom!linus!philabs!polaris!josh
From: josh@polaris.UUCP (Josh Knight)
Newsgroups: net.arch
Subject: Re: Floating point performance (really long integer arithmetic)
Message-ID: <753@polaris.UUCP>
Date: Sat, 18-Oct-86 14:03:23 EDT
Article-I.D.: polaris.753
Posted: Sat Oct 18 14:03:23 1986
Date-Received: Tue, 21-Oct-86 22:48:14 EDT
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <725@mips.UUCP> <6028@ut-sally.UUCP> <16112@mordor.ARPA>
Reply-To: josh@polaris.UUCP (Josh Knight)
Organization: IBM Research, Yorktown Heights, N.Y.
Lines: 46
Keywords: numerical analysis, loss of precision
Summary: you wouldn't want to even if you could

In article <16112@mordor.ARPA> ehj@mordor.UUCP (Eric H Jensen) writes:
>In article <6028@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>>more complex (and slower) using standard hardware.  Also, the aphorism
>>about using a lot of floating operations was brought home to me:
>>"Using floating point is like moving piles of sand around.  Every time
>>you move one you lose a little sand, and pick up a little dirt."
>
>I thought numerical analysis was the plastic sheet you place your sand
>on - with some thought (algorithm changes) you can control your
>errors most of the time or at least understand them.  Then of course
>there is always an Extended format ...
>

There are two realistic limits to the precision used for a particular
problem, assuming that the time to accomplish the calculation is not
an issue.  The first is the precision of the input data (in astronomy
this tends to be less than single precision, somtimes significantly
less) and the second is the number of intermediate values you are willing
to store in your calcuation (i.e. memory).  The number of intermediate
values includes things like the fineness of the grid you use in an
approximation to a continuous problem formulation (although quantum
mechanics makes everything "grainy" at some point, numerical calculations
aren't usually done to that level).  As Eric points out, proper handling
of the calcuations and some extended precision (beyond what is kept in long
term storage) will provide all the precision that is available with the
given resources.  Indeed, the proposal to use long integers is wasteful
of the very resource that is usually in short supply in these calculations,
namely memory (reference to all the "no virtual memory MY Cray!" verbage).
When Ed stores the mass of a 10 solar mass star in his simulation of the
evolution of an open cluster as a 512 bit integer, approximately 500 of
the bits are wasted on meaningless precision.  The mass of the sun is
of order 10e33 grams, but the precision to which we know the mass is only
five or six decimal digits (limited, I believe, by the precision of G, the
gravitational coupling constant, but the masses of stars other than the
sun are typically much more poorly known), thus storing this number in
a 512 bit integer wastes almost all the bits, only 15-20 of them mean
anything.

I'll admit (before I get flamed) that the IBM 370 floating point format
has some deficiencies when it comes to numerical calculations (truncating
arithmetic and hexadecimal normalization).  I will also disclaim that
I speak only for myself, not my employer.
-- 

	Josh Knight, IBM T.J. Watson Research
 josh@ibm.com, josh@yktvmh.bitnet,  ...!philabs!polaris!josh