hrubin@pop.stat.purdue.edu (Herman Rubin) (06/24/91)
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)