Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!rutgers!lll-crg!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: Floating point performance (really long integer arithmetic)
Message-ID: <1214@hoptoad.uucp>
Date: Wed, 22-Oct-86 07:24:58 EDT
Article-I.D.: hoptoad.1214
Posted: Wed Oct 22 07:24:58 1986
Date-Received: Wed, 22-Oct-86 22:49:29 EDT
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <753@polaris.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 16
Keywords: numerical analysis, loss of precision

In article <6028@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>"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."

IEEE floating point requires an "exact" mode which causes a trap any
time the result of an operation is not exact.  This lets your
software know that it has picked up dirt, if it cares, and lets
particularly smart software change to extended precision, long integers,
or whatever.

I was wondering how you represent values <1 in your 512-bit integers...
or are you going to figure out binary points on the fly?  In that case
you might as well let hardware do it -- that's called floating point!
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
(C) Copyright 1986 by John Gilmore.             May the Source be with you!