Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Side effects in boolean expressions
Message-ID: <60198@lanl.gov>
Date: 15 Aug 90 21:45:46 GMT
References: <2041@key.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 39

From article <2041@key.COM>, by sjc@key.COM (Steve Correll):
> [...]
> 	if ((x < 0.0) || (sqrt(x) < 10.0)) ...
> 	IF ((X .LT. 0.) .OR. (SQRT(X) .LT. 10.0)) ...
> 
> If x is negative, a legal C processor will not call sqrt, but a legal Fortran
> processor may or may not--in fact, it could vary with the phase of the moon!
> By refusing to define the order of evaluation, Fortran gives the processor
> more freedom (e.g. to optimize).

So, the C definition _requires_ me not to make the optimization I want
to make (namely, starting the SQRT in parallel with the test of X).
Meanwhile, the Fortran (as you say) is completely unpredictable on this
point.

And, when trying to formally analyze the _meaning_ of the program, _neither_
Fortran nor C allows me to treat the 'or' operator as commutative - even
though _mathematically_ it _is_!  To be sure, a short circuit boolean
is occasionally useful - but the ordinary mathematical kind is _much_
more common.  For this reason, the two concepts should be separately
available in a programming language.  For the above, I would prefer
something like:

      if (x < 0) or if (sqrt(x) < 10.0) then ...  !or _outside_ conditions
						  !is short circuited
      if (x < 0 \/ sqrt(x) < 10.0) then ...       !or '\/' operator _inside_
						  !conditions is commutative

Of course, the second of these will frequently die from evaluating sqrt()
on a negative operand.  But, this kind of problem is comparatively rare.

In this example, of course, it is more efficient to do the test as
follows anyway:

      if (x < sqrt(10.0)) then ...

This has the same effect and completely avoids the problem.

J. Giles