 |
 |
From: SMTP%"[log in to unmask]" 14-JAN-2000 10:01:11.48 > >the order of evaluation of operators in some cases. For example, with > > > > a*(b*c) > > > >the compiler is required to do the b*c operation "logically before" > >the a*() one. (I use the quotes because the issue can actually get > >subtle. But the subtleties aren't what is at issue here. We are > >discussing the most fundamental of this class of issues). > > IIRC, Dick Hendrickson suggested/implied that the compiler could still > do what it wanted in a bracketed condition: IF((A.EQ.0).OR.(B.EQ.0)) > (for simpilicity). > > O.K., I've always believed that and worked my conditions accordingly. > > However, why cannot the compiler be permitted to understand the > commutative/associative/distributive laws of arithmetic? Requiring things in parentheses to be evaluated first is helpful to prevent overflow etc. This is clearer than using temporary variables. One wants to PROHIBIT optimisation in these cases, since it could lead to overflow etc. > Most occassions will > give "correct" results The rule is needed for the rest of the cases. > and possibly optimise better. Why? > Formula Translation. "Special" results can be obtained by using temporary > variables which usage should not be assumed to be part of any of these laws. Is it possible that, back in the early days, temporary variables would have been frowned upon due to greater memory usage? (After all, this was the original motivation for EQUIVALENCE, I believe.) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%