jlg@lanl-a.UUCP (07/12/84)
>C explicitly does NOT rearrange most arithmetic operations >(exceptions are supposedly commutative operators). That's not the problem. C rearranges 'supposedly' associative operations, even when the expression has been parenthesized to prevent it. For example: a = b + (c + d); The C compiler may (and frequently does) do (b+c)+d or (b+d)+c instead of b+(c+d). Since floating point addition is NOT associative, the two rearrangements may give incorrect answers. The problem is magnified when there is a large expression to be compiled with several non-associative adds present -- often the result from C is completely unpredictable. This is probably one of the reasons that ALL C arithmetic is double precision, i.e. so that bad instruction scheduling won't be noticed as often. J.L.Giles ...inhp4!cmcl2!lanl-a!jlg
gwyn@Brl-Vld.ARPA (07/16/84)
From: Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> Yes, C also reassociates supposedly associative operators as in a = b + (c + d); This issue is being discussed in the ANSI standardization effort. Meanwhile, one can obtain the desired associativity by breaking the computation up into substatements; admittedly not as nice as letting parentheses determine order of evaluation, but guaranteed to work. It is a bit unfair to expect C to follow Fortran rules rather than its own; if the rules should be changed then let the standards people know and maybe they will be (if possible without breaking existing code). The reason C floating arithmetic is in double precision is that the PDP-11 FP11 design made that the most reasonable way to do business. Now that C exists on practically all CPU architectures, this is not a very good reason, and it could be changed. Again, the ANSI C standards committee appears to be ready to make single- precision floating point a full family member.
jlg@lanl-a.UUCP (07/19/84)
>Yes, C also reassociates supposedly associative operators as in > a = b + (c + d); >This issue is being discussed in the ANSI standardization effort. >Meanwhile, one can obtain the desired associativity by breaking >the computation up into substatements; admittedly not as nice as >letting parentheses determine order of evaluation, but guaranteed >to work. It is a bit unfair to expect C to follow Fortran rules >rather than its own; if the rules should be changed then let the >standards people know and maybe they will be (if possible without >breaking existing code). But it's NOT unfair to point out that this problem is a weakness of C! After all the subject of this exchange is "Fortran vs. C". J.L. Giles
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/20/84)
My point was that the C feature of not forcing evaluation order based on parentheses but instead requiring use of separate statements is not necessarily a "weakness of C". The reason you perceive it as such is that your idea of the meaning of parentheses is borrowed from Fortran. In this case, I believe the C language could be changed to adopt the Fortran meaning for parentheses in expressions, which would occasionally (not often) be useful. However, in C as currently defined it is nevertheless possible to specify evaluation order; you just can't do it using Fortran ideas.