Richard, [with snips to the bit that I find interesting]
>It is at least possible that you are confusing short-circuit
>evaluation with the order of operations. The question starting this
>thread was about short-circuiting. Parentheses can be used to control
>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? Most occassions will
give "correct" results and possibly optimise better. This is, after all,
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.
Hence, a*(b*c) is no different from (a*b)*c or even a*c*(b) for reals, but
temp=b*c; a*temp is for computer reals. And include the definitions of all
above laws.
Regards, Paddy
Paddy O'Brien,
Transmission Development,
TransGrid,
PO Box A1000, Sydney South,
NSW 2000, Australia
Tel: +61 2 9284-3063
Fax: +61 2 9284-3050
Email: [log in to unmask]
Either "\'" or "\s" (to escape the apostrophe) seems to work for most people,
but that little whizz-bang apostrophe gives me little spam.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|