Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran versus C for numerical analysis
Message-ID: <349@quintus.UUCP>
Date: 3 Sep 88 08:11:54 GMT
References: <344@quintus.UUCP> <2932@hubcap.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 43

In article <2932@hubcap.UUCP> fpst@hubcap.UUCP (Steve Stevenson) writes:
>From article <344@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe):
>> What I meant was that there is no method of saying "this grouping is
>> just syntactic so that I can read the expression, mathematical laws may
>> be applied".
>
>I'm afraid that "mathematical laws" are not numerical laws.
>You are not free to permute and mess with expressions because the
>programmer is taking great pains to keep numerical error right where
>he or she wants it.

I know perfectly well that computer arithmetic doesn't follow the usual
laws of algebra.  *IF* I have taken great pains to control numerical
error, then yes indeed I want it done the way I wrote it.  But in that
case, it is quite likely that I have given the individual parts of the
expression names so that I could say things about their error bounds in
my proof that this was the right way to compute the expression...

But it is not the case that all Fortran code is written by, or with the
aid of, numerical analysts.  I haven't seen a great deal of Fortran
code, but apart from statistical packages, most of the Fortran programs
I've seen were written by physicists.  Their Fortran expressions were
derived from mathematical expressions which *DID* obey the standard
algebraic laws.  They had enough trouble translating their formulas
into a weirdly limited character set, so the better ones coded their
formulas with desk-checking in mind, _not_ numerical analysis.  Now, if
your floating point instructions signal overflow *and* underflow (and
inexact if you've got it), and if you have well-written library packages,
it's ok for the compiler to rearrange the expressions to its convenience
because the programmer didn't have a particular arrangement in mind.

I am not alleging that the programmer *never* has a particular arrangement
in mind, only that *some* expressions are carefully ordered and *some* are
not, and "(A+B)+C -because-it-must-be-done-that-way-for-numerical-reasons"
and "(A+B)+C -because-that's-the-way-Thingy's-paper-wrote-the-original-
formula" are different things that deserve different notation.

Ideally, of course, we would have a language where the compiler could be
given information about the range of variables and the criterion it would
optimise in compiler-has-a-free-hand expressions would be numerical
accuracy.  Alternatively, some sort of preprocessor which points out
possible numerical problems and suggests improvements?  It seems to me
that even something fairly simpleminded might at least provide a useful
place to start.