🚀 go-pugleaf

In article <6478@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> In article <1991Jun22.003029.16748@watson.ibm.com>,
> prener@watson.ibm.com (Dan Prener) writes:
> > As immodest as it might be for me to agree with my colleague, I must
> > agree with James Shearer.  Indeed, the spirit of FORTRAN is, overwhelmingly,
> > that a program whose behavior is changed by optimization is not a legal
> > program.
> 
> In that case, a subroutine like	
> 	SUBROUTINE FOO(X, A, B, C)
> 	    REAL X, A, B, C
> 	    X = A*B + A*C
> 	END
> must not be legal.  Darn it, I used to _like_ Fortran.  (Yes, optimisation
> _may_ change the behaviour of this program in a signficant way.)  Perhaps
> more obviously,

Something like this occurs in most trigonometric and exponential routines,
for accuracy.  Another real example is quick accurate computation of 

	f(x) = x - ln(1+x)

If we set 1+x = 2^k*(1+y), where 2^(-.5)<= y < 2^.5, then 

	f(x) = ((x-y) - k*ln(2.)) + f(y)

Especially for k = 1 or k = -1, there is about a 5-bit loss of accuracy 
in evaluating the simple-looking terms in parentheses!  The greater
accuracy is fully justified, and it is necessary to have ln(2.) to more
than the precision wanted.  In this case, forcing parentheses will do
the job, but this is both technically and actually breaking certain kinds
of optimization.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)