Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!think.com!snorkelwacker.mit.edu!ai-lab!life!burley From: burley@pogo.gnu.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.fortran Subject: Re: Questions about IF Message-ID: Date: 25 Jun 91 14:37:29 GMT References: <1991Jun24.213601.11329@milton.u.washington.edu> <26384@lanl.gov> <1991Jun25.124806.15349@cs.dal.ca> Sender: news@ai.mit.edu Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 Lines: 51 In-reply-to: silvert@cs.dal.ca's message of 25 Jun 91 12:48:06 GMT In article <1991Jun25.124806.15349@cs.dal.ca> silvert@cs.dal.ca (Bill Silvert) writes: In article <26384@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >Actually, the standard does require that no optimization >violate parenthesis. So you can force the order of >evaluation any way you want: > > If (expr1 .and. (expr2.and.expr3)) then > ... > >This does the second '.and.' first. The other question was about >short-circuiting: the standard _allows_ short-circuiting but does >not _require_ it. Sorry, this doesn't make sense to me. All the parentheses guarantee is that expr1 will not be evaluated second. Both the sequences 1-2-3 and 3-2-1 are consistent with the given parentheses. As I understand the standard, ANY sequence of evaluation of expr1, expr2, and expr3 is valid. What the parentheses do is ensure that the second .and. is evaluated as written. In other words, the system (compiler) may evalute expr3 first, expr1 second, and expr2 third. Then it must evaluate (expr2.and.expr3) (the exprns already having been evaluated, so they now represent the results of those evaluations), because the result is needed in evaluating expr1.and.result (or anything logically equivalent, according to the standard). The upshot is, in my opinion, there is basically no need for parentheses in logical or relational expressions in Fortran except to enforce or override precedence. (There's no need for them at all in character expressions, since only one character operator, //, exists.) In arithmetic expressions, parentheses are useful to ensure an order of operator (_not_ operand) evaluation that might prevent overflow compared to some other order. For example, in A+(B+C), A, B, and C may be evaluated in any order, but the parentheses ensure that B and C are added together and the result added to A, instead of possibly adding A and B together or A and C, and this might reduce the possibility of overflow (or underflow). In summary: parentheses in Fortran do not restrict the order of evaluation of operands, just the way in which operators are applied to their operands. (This is my opinion; if you think otherwise, please point me to the applicable spot in the standard. I'm using Section 6.6.3 page 6-17, "Integrity of Parentheses", as a guide, and the wording is a bit ambiguous, but the sentence beginning "For example" seems to indicate that what is at issue is the evaluation of operators, not operands. 6.6.2 seems to back this up, implying that a processor (compiler) may evaluate the function references in the expression "F1(X)*(F2(X)*F3(X))" in any order.) -- James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu