🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #3121

Re: Floating point performance

#3121
From: Dik T. Winter
Date: Sat, 08 Nov 1986 20:43
48 lines
3214 bytes
In article <570@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes:
>In article <BMS-AT.253> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes:
>>
>>                 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.
>
Well, there are at least three packages dealing with it: ACRITH from IBM
and ARITHMOS from Siemens (they are identical in fact) and a language called
PASCAL-SC on a KWS workstation (a bit obscure I am sure).  They are based
on the work by Gulisch et al. from the University of Karlsruhe.  They
use arithmetic with directed rounding and accumulation of dot products
in long registers (168 bytes on IBM).  On IBM there is microcode support
for this on the 4341 (or 4381 or 43?? or some such beast).

The main purpose is verification of results (at least, that is my opinion).
For instance on a set of linear equations find a solution interval that
contains the true solution with the constraint that the interval is as
small as possible.  They then first proceed finding an approximate solution
using standard techniques followed by an iterative scheme to obtain a
smallest interval using interval arithmetic combined with long registers.
This is superior toi standard interval arithmetic because the latter tends
to give much too large intervals.
-- 
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo,decvax,philabs,okstate,garfield}!mcvax!dik
  or: dik@mcvax.uucp
ARPA: dik%mcvax.uucp@seismo.css.gov
Technical Details
Message-ID: <317@zuring.mcvax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!mcvax!dik
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <6028@ut-sally.UUCP> <BMS-AT.253> <570@cubsvax.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!mcvax!dik
From: dik@mcvax.uucp (Dik T. Winter)
Newsgroups: net.arch
Subject: Re: Floating point performance
Message-ID: <317@zuring.mcvax.UUCP>
Date: Sat, 8-Nov-86 15:43:38 EST
Article-I.D.: zuring.317
Posted: Sat Nov  8 15:43:38 1986
Date-Received: Sun, 9-Nov-86 04:16:27 EST
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <6028@ut-sally.UUCP> <BMS-AT.253> <570@cubsvax.UUCP>
Reply-To: dik@zuring.uucp (Dik T. Winter)
Organization: CWI, Amsterdam
Lines: 47
Apparently-To: rnews@mcvax