merlyn@starfire.UUCP (Brian Westley) (04/21/87)
Adding my $.02 about this whole order of evaluation to-do; 1) C allows the compiler to rearrange expressions involving communative & associative operators (+*^&| etc) 2) C, unfortunately, lumped both kinds of + together (integer add, float add). Integer addition is communative & associative. Floating addition is communative, but NOT associative. C 'defines' it to be something it isn't. I would prefer a compiler that doesn't perform associative transformations with operators that aren't associative. (For all you people about to yell "parentheses affect precidence, not order of evaluation", just consider (a%b)%c vs. a%(b%c) - if the %'s were +'s, the expression can be rearranged, but as written, it cannot, since % isn't associative or communative). 3) Does the proposed standard consider floating + to be associative? I hope it doesn't, since it isn't, C history notwithstanding. It probably does, though. +(We must be upward compatible with past errors). 4) Of course, (f1 + f2 + f3) should be rearrange-able, simple left-to-right associativity should be 'weaker'. 5) The same holds for most floating operations. ---- Merlyn Leroy ..rutgers!dayton!rosevax!rose3!starfire!merlyn
manis@ubc-cs.UUCP (Vincent Manis) (04/23/87)
In article <133@starfire.UUCP> merlyn@starfire.UUCP (Brian Westley) writes: >Integer addition is communative [sic] & associative. Floating addition is >communative, but NOT associative. >Merlyn Leroy ..rutgers!dayton!rosevax!rose3!starfire!merlyn This statement is flat-out wrong. On a machine with 16-bit ints 32767 + (-2) + 1 and 32767 + 1 + (-2) may lead to different results. It so happens that both will "work" on some machines with 2's complement, but 2's complement is only mandated by the Draft Standard (according to Harbison and Steele) for unsigned, not signed, ints. Even on some 2's complement machines, such as the IBM 370, there are modes in which the second expression will cause a fault (though fixed overflow checking is generally disabled). ----- Vincent Manis {seismo,uw-beaver}!ubc-vision!ubc-cs!manis Dept. of Computer Science manis@cs.ubc.cdn Univ. of British Columbia manis%ubc.csnet@csnet-relay.arpa Vancouver, B.C. V6T 1W5 manis@ubc.csnet (604) 228-6770 or 228-3061 "Long live the ideals of Marxism-Lennonism! May the thoughts of Groucho and John guide us in word, thought, and deed!"
merlyn@starfire.UUCP (Brian Westley) (04/26/87)
Vincent Manis writes: > I write: > >Integer addition is communative [sic] & associative. Floating addition is > >communative, but NOT associative. [oops, s/communative/commutative/g - Ed] > > This statement is flat-out wrong. On a machine with 16-bit ints > > 32767 + (-2) + 1 > > and > > 32767 + 1 + (-2) > > may lead to different results....[etc] Yes, but I wasn't talking about expressions that lead to overflow (which is another kettle of fish, since your version of C may or may not rearrange integer expressions, which may or may not produce an integer overflow, which may or may not be trapped as an error, which may or may not produce the correct answer ANYWAY, depending on your machine & compiler). I was talking of the general case of: (1 + 9999) + (-9999) (same no matter how you slice it) vs. (1 + 9E99) + (-9E99) (not the same) I am also not against +(), as integer overflow is a case where order of evaluation is important (but I like the suggested [] notation better). I was just against compilers performing associative transformations on operators that aren't associative, PERIOD. As other people have pointed out, a compiler isn't REQUIRED to rearrange floating-point expressions associatively, and if there is enough demand for such behavior, maybe it will become a de facto "standard". Merlyn Leroy ...rutgers!dayton!rosevax!rose3!starfire!merlyn