ambiguous ?

[Jim Giles]

>From article <1989Oct21.072905.9039 at utzoo.uucp>, by henry at utzoo.uucp (Henry Spencer):
> In article <14102 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
>>If it involves compromises of correctness, the language is not worth
>>pursuing...
> How can you possibly bear to use floating-point arithmetic, then?  No
> floating-point representation on any actual machine correctly implements
> the real numbers (despite misuse of the word "REAL" in Fortran). [...]

Floating point arithmetic implements, on any given machine, a well defined
set of rational numbers as well as an algebra of operations on that set.
It is possible to implement _stable_ algorithms for this set of numbers
which are useful in many applications.  This is not simple, but as it is
a very _valuable_ thing to do, it is well worth pursuing.  If this
numerical approach compromises correctness (either by not using stable
algorithms, or leaving the reagon of stability) then it is indeed a waste
of effort.

> [...]                 The reasoning required for this is orders of
> magnitude more complex than anything needed to deal with C's compromises.

A strange claim since C contains the self-same problems with floating-point
as any other modern programming language.  More, in fact!  C doesn't contain
a mechanism for forcing the evaluation order of an expression.  Seems like 
we've just been discussing this.

> Most Fortran programmers, of course, either don't bother at all or use
> what Ric Hehner has dubbed "engineering induction":  "if it works for
> n = 1, 2, and 3, that's good enough for me".

Gee, I don't know _any_ programmers that use the above claimed 'induction'.
Most scientific programmers I know are very concerned about the stability
of their algorithms.  Most programming effort in Fortran seems to be
concerned with this.