Re: C values that are not known at compile time

Chris Bore wrote:

It is compiler-dependent if an expression like
float x,a,b,c;
x = a+b-c;
is implemented as
x1 = a + (b-c);
or
 x2 = (a+b)-c;



I think the order of evaluation of floats is well-defined. Some
compilers choose to ignore the rules for reasons of speed, which means
their results differ even with the same code and same compiler
depending on optimization level (first rule of optimization - code
should always give same result..). So I think one of your compilers was
flaky - I think the Texas compiler for their 'C40 processors let itself
change float evaluation order, to increase speed, but that is not
correct. The compiler might allow you to break the float ordering rule,
but that should be an explicit option.

In fact the required order of evaluation of floats (wihin a statement)
is one thing that hampers parallel compilers - because they are not
allowed to change the order and so cannot exploit potential
paralellism. Float arithmtic is not associative, so a+(b-c) is not
equal to (a+b) -c you can see this if you make a and b very large and
very small respetcively.

Chris


It all depends on whether the compiler aims to be ANSI compliant. that standard defines both the precedence ~and~ the associativity of operators; e.g unary operators are right-associative, binary ones are left-associative, which means that in an expression "a + b - c - d" where the operators are at the same precedecne level, operations will be calculatew from left to right:

((a+b)-c)-d

And the indirection unary operators & and * have a higher precedence than the binary arithmetic operators * and /, so

&a[2] always means &(a[2])

If the compilers are not ANSI-compliant, all bets are off, and all one can do is RTFM, if there is one, and if not, hope+pray.

In ANSI C float types are not treated in any special way, so expressions involving floats obey the same precedence and associativity rules as any other numeric type. It is up to the programmer to worry about rounding errors, etc, and thus to arrange calculation order effectively. Again, if the compiler elects to disregard ANSI rules, anything is possible, except generalisations and portability.


Richard Dobson








Richard Dobson
.

Relevant Pages

  • Re: warning: dereferencing `void * pointer
    ... >I have some functions which take as i/p a buffer (it can be float, char, ... how the systemyou use interpret bits. ... find yourself having to "help" some compilers a bit. ...
    (comp.lang.c)
  • Re: C values that are not known at compile time
    ... I think the order of evaluation of floats is well-defined. ... So I think one of your compilers was ... change float evaluation order, to increase speed, but that is not ... The compiler might allow you to break the float ordering rule, ...
    (comp.dsp)
  • Re: Visual C++ Express wont compare object against float in std::upper_bound
    ... Sample (float value, float position): ... friend bool operator< ... friend bool operator<(float position, const Sample& rhs); ... of these compilers or their implementations of the STL. ...
    (microsoft.public.vc.stl)
  • Re: why system providing routies will provide different result in C++ and Fortran
    ... The sqrtf() man pages I find seem to indicate C99. ... So Fortran had sqrtfand sinf. ... Otherwise variables have to be declared either double or float. ... Likewise, float expression evaluation was promoted to double, and there are still compilers which do that in their usual language standard compliance mode. ...
    (comp.lang.fortran)
  • Re: Silly question...ANSWER!
    ... > it works out all the post fixes first, ... > takes precedence... ... You can't rely on your analysis, because compilers are ... free to do this kind of stuff in all kinds of crazy orders. ...
    (alt.comp.lang.learn.c-cpp)