Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uokvax.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!okstate.UUCP!uokvax.UUCP!emjej
From: emjej@uokvax.UUCP
Newsgroups: net.lang.c
Subject: Re: C Floating point arithmetic
Message-ID: <3000069@uokvax.UUCP>
Date: Mon, 2-Dec-85 12:29:00 EST
Article-I.D.: uokvax.3000069
Posted: Mon Dec  2 12:29:00 1985
Date-Received: Fri, 6-Dec-85 07:09:05 EST
References: <3369@brl-tgr.ARPA>
Lines: 23
Nf-ID: #R:brl-tgr.ARPA:3369:uokvax.UUCP:3000069:000:1214
Nf-From: uokvax.UUCP!emjej    Dec  2 11:29:00 1985


Sigh...people, including those who feel that C is perfect and thus have
the urge to defend its every jot and tittle to the death, at times have
such a touching faith in double precision! :-)

I am in no wise a numerical analysis guru, but I have studied under one,
and if there is one thing I have learned, that is that if your algorithm
is flawed or your problem ill-conditioned, no amount of precision will
save you.  The fellow commenting on the fuzziness of the input data has an
extremely valid point: an ill-conditioned problem may be such that wildly
different solutions (and hence physical behavior of a system being modeled)
are well within the possible "true" values of the inputs to your number
cruncher.

Also, I recall that in matrix hacking, it turns out that certain
operations are crucial--notably accumulating dot products.  If you do
*these* in high precision, the rest of the stuff can get away with less.
That can make a large difference in storage space and runtime (if you
have hardware that was designed like C so that everything is done in
max precision anyway, the runtime difference is less, I'd agree, but
people beat on some hefty matrices nowadays--thrash, thrash).

						James Jones