Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!pyrnj!esquire!cmcl2!rna!cubsvax!peters
From: peters@cubsvax.UUCP (Peter S. Shenkin)
Newsgroups: net.arch
Subject: Re: Floating point performance
Message-ID: <570@cubsvax.UUCP>
Date: Thu, 23-Oct-86 13:42:50 EDT
Article-I.D.: cubsvax.570
Posted: Thu Oct 23 13:42:50 1986
Date-Received: Fri, 24-Oct-86 17:06:14 EDT
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <6028@ut-sally.UUCP> <BMS-AT.253>
Reply-To: peters@cubsvax.UUCP (Peter S. Shenkin)
Organization: Columbia Univ. Bio. CG Fac., NY
Lines: 37

In article <BMS-AT.253> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes:
>
>For problems appropriate to floating point, the input is already
>imprecise.  Planck's constant is not known to more than a dozen
>digits at most.  Good floating point software keeps track of
>the remaining precision as computations proceed.

???  I've never heard of this.  Could you say more?  Until you do, I will....
Read on.

>							...Rounding
>in floating point hardware contributes only a minor portion of
>the imprecision of the result in properly designed software.

I disagree.  Consider taking the average of a many floating point numbers
which are read in from a file, and which differ greatly in magnitude.
How many there are to average may not be known until EOF is encountered.
The "obvious" way of doing this is to accumulate the sum, then divide
by n.  But if some numbers are very large, the very small ones will
fall off the low end of the dynamic range, even if there are a lot of
them;  this problem is avoided if one uses higher precision (double
or extended) for the sum.  If declaring things this way is what you mean by 
properly designed software, OK.  But the precision needed for intermediate 
values of a computation may greatly exceed that needed for input and
output variables.  I call this a rounding problem.  I know of no "floating
point software" that will get rid of this.  There are, of course, programming
techniques for handling it, some of which are very clever.  Again, I suppose
you could say that if you don't implement them then you're not using 
properly designed software.  But these techniques are time-consuming to
build in to programs, and time consuming to execute;  therefore, they
should only be used where they're really needed.  But the whole point is that
the precision needed for intermediate results may GREATLY exceed that needed 
for input and output variables, and an important part of numerical analysis
is being able to figure out where that is.

Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
{philabs,rna}!cubsvax!peters		cubsvax!peters@columbia.ARPA