parenthesis

Discussion in 'C Programming' started by gc, Oct 16, 2003.

  1. gc

    gc Guest

    If I have double variables, d,u,v,w,x. Soes the standard ensure that
    while
    assigning a value to d as,
    d=(u+v)-(w+x);
    u+v will be added first then w+x and then they will be added together
    and that the compiler will not evaluate the above expression in
    anyother order.

    Just wondering, since addition of doubles is not associative.
    gc, Oct 16, 2003
    #1
    1. Advertising

  2. gc

    Grumble Guest

    gc wrote:
    > If I have double variables, d,u,v,w,x. Soes the standard ensure that
    > while
    > assigning a value to d as,
    > d=(u+v)-(w+x);
    > u+v will be added first then w+x and then they will be added together
    > and that the compiler will not evaluate the above expression in
    > anyother order.
    >
    > Just wondering, since addition of doubles is not associative.


    The subtraction will be carried out last, but AFAIK the additions
    could be done in either order. If you want to force a specific
    evaluation order, you could use an extra variable.
    Grumble, Oct 16, 2003
    #2
    1. Advertising

  3. gc wrote:
    > If I have double variables, d,u,v,w,x. Soes the standard ensure that
    > while assigning a value to d as,
    > d=(u+v)-(w+x);
    > u+v will be added first then w+x


    No, neither the C standard nor the C++ standard guarantee that. (w+x) might
    be evaluated before (u+v).

    --
    Russell Hanneken

    Remove the 'g' from my address to send me mail.
    Russell Hanneken, Oct 16, 2003
    #3
  4. In article <bmljkn$86h$>, Grumble wrote:
    > gc wrote:
    >> If I have double variables, d,u,v,w,x. Soes the standard ensure that
    >> while
    >> assigning a value to d as,
    >> d=(u+v)-(w+x);
    >> u+v will be added first then w+x and then they will be added together
    >> and that the compiler will not evaluate the above expression in
    >> anyother order.
    >>
    >> Just wondering, since addition of doubles is not associative.

    >
    > The subtraction will be carried out last, but AFAIK the additions
    > could be done in either order. If you want to force a specific
    > evaluation order, you could use an extra variable.
    >


    double t1, t2;

    t1 = u + v;
    t2 = w + x;

    d = t1 - t2;


    AFAIK, there's nothing stopping the compiler from generating
    code that calculates t2 before t1.

    I'm not sure the finer details of floating point arithmetics is
    an issue here at all.

    --
    Andreas Kähäri
    Andreas Kahari, Oct 16, 2003
    #4
  5. gc

    Richard Bos Guest

    (gc) wrote:

    > If I have double variables, d,u,v,w,x. Soes the standard ensure that
    > while
    > assigning a value to d as,
    > d=(u+v)-(w+x);
    > u+v will be added first then w+x and then they will be added together
    > and that the compiler will not evaluate the above expression in
    > anyother order.


    No.

    > Just wondering, since addition of doubles is not associative.


    True, but it shouldn't matter at all in which order the two
    sub-expressions are evaluated. This:

    - add u and v; remember the result.
    - add w and x; remember the result.
    - subtract the second result from the first.

    should give the same answer as this:

    - add w and x; remember the result.
    - add u and v; remember the result.
    - subtract the first result from the second.


    The problem only starts when you do things like

    a=b+c+d;

    because then, for floating point objects, (b+c)+d can give very
    different results from b+(c+d). And indeed, the Standard prohibits
    implementations from optimising that kind of expression too
    enthusiastically. For example,

    a=x+y+z;
    b=w+y+z;

    cannot be optimised into

    t=y+z
    a=x+t;
    b=w+t;

    because that might give different results. Contrariwise,

    a=y+z+x;
    b=y+z+w;

    _can_ be optimised to

    t=y+z
    a=t+x;
    b=t+w;


    But your example does not have this problem.

    Richard
    Richard Bos, Oct 16, 2003
    #5
  6. Grumble <> wrote:

    >gc wrote:
    >> If I have double variables, d,u,v,w,x. Soes the standard ensure that
    >> while
    >> assigning a value to d as,
    >> d=(u+v)-(w+x);
    >> u+v will be added first then w+x and then they will be added together
    >> and that the compiler will not evaluate the above expression in
    >> anyother order.
    >>
    >> Just wondering, since addition of doubles is not associative.

    >
    >The subtraction will be carried out last, but AFAIK the additions
    >could be done in either order. If you want to force a specific
    >evaluation order, you could use an extra variable.


    Why use an extra variable?

    d = u + v;
    d -= w + x;

    Regards
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Oct 16, 2003
    #6
  7. On Thu, 16 Oct 2003, Andreas Kahari wrote:
    >
    > In article <bmljkn$86h$>, Grumble wrote:
    > > gc wrote:
    > >>
    > >> If I have double variables, d,u,v,w,x. Soes the standard ensure that
    > >> while assigning a value to d as,
    > >> d=(u+v)-(w+x);
    > >> u+v will be added first then w+x and then they will be added together
    > >> and that the compiler will not evaluate the above expression in
    > >> anyother order.
    > >>
    > >> Just wondering, since addition of doubles is not associative.


    The order of operations is not specified, except that (w+x) will be
    subtracted from (u+v); the compiler can't decide to subtract w from
    (u+v), and then subtract x from the result, *UNLESS* the answer would
    be exactly the same (the "as if" rule) -- in which case who cares how
    it was computed?

    > > The subtraction will be carried out last, but AFAIK the additions
    > > could be done in either order. If you want to force a specific
    > > evaluation order, you could use an extra variable.

    >
    > double t1, t2;
    >
    > t1 = u + v;
    > t2 = w + x;
    >
    > d = t1 - t2;
    >
    > AFAIK, there's nothing stopping the compiler from generating
    > code that calculates t2 before t1.


    Practically, that's true. However, the code *must* behave *AS IF*
    t1 was calculated before t2, because the semicolons introduce
    sequence points.

    > I'm not sure the finer details of floating point arithmetics is
    > an issue here at all.


    On some systems (which may or may not be conforming, I don't know;
    I don't follow floating-point stuff :), we can have

    double d = 3.14;
    double e = 4.72;
    double f = d/e;
    printf("%g %g\n", f, d/e);

    and get two different numbers, because the FPU registers use
    slightly wider representations than the actual type 'double'
    objects. That's why order-of-operations matters in general,
    in practice.
    And specifically about associativity, you know that

    double d = 1e10, e = 5, f = 5;
    double r1, r2;
    r1 = (d+e)+f;
    r2 = d+(e+f);

    can produce (r1 != r2) (for suitable values of 5, of course).
    It's plausible that something like that could be at stake
    in the OP's code; I don't feel like running through all possible
    values of (u,v,w,x) right now. ;-)

    HTH,
    -Arthur
    Arthur J. O'Dwyer, Oct 16, 2003
    #7
  8. In article
    <>,
    Arthur J. O'Dwyer wrote:
    >
    > On Thu, 16 Oct 2003, Andreas Kahari wrote:
    >>
    >> In article <bmljkn$86h$>, Grumble wrote:

    [cut]
    >> > The subtraction will be carried out last, but AFAIK the additions
    >> > could be done in either order. If you want to force a specific
    >> > evaluation order, you could use an extra variable.

    >> t1 = u + v;
    >> t2 = w + x;
    >>
    >> d = t1 - t2;
    >>
    >> AFAIK, there's nothing stopping the compiler from generating
    >> code that calculates t2 before t1.

    >
    > Practically, that's true. However, the code *must* behave *AS IF*
    > t1 was calculated before t2, because the semicolons introduce
    > sequence points.


    In this example, there will not be any difference to the result
    if u+v is evaluated before/after w+x. The OP's concern is
    without foundation.

    However, if the question was if there was a difference between
    "u+v-w+x" and "(u+v)-(w+x)", then the answer is clearly yes,
    depending on the magnitude and sign of the involved floating
    point numbers.


    --
    Andreas Kähäri
    Andreas Kahari, Oct 16, 2003
    #8
  9. On Thu, 16 Oct 2003, Andreas Kahari wrote:
    >
    > Arthur J. O'Dwyer wrote:
    > > On Thu, 16 Oct 2003, Andreas Kahari wrote:
    > >>
    > >> AFAIK, there's nothing stopping the compiler from generating
    > >> code that calculates t2 before t1.

    > >
    > > Practically, that's true. However, the code *must* behave *AS IF*
    > > t1 was calculated before t2, because the semicolons introduce
    > > sequence points.

    >
    > In this example, there will not be any difference to the result
    > if u+v is evaluated before/after w+x. The OP's concern is
    > without foundation.


    But some compilers like to aggressively optimize arithmetic, turning
    (u+v)-(w+x) into (u+v-w-x) or similar, and in *that* case there's
    definitely a difference!

    > However, if the question was if there was a difference between
    > "u+v-w+x" and "(u+v)-(w+x)", then the answer is clearly yes,

    ^^^^^^^ ^^^^^^^^^^^
    > depending on the magnitude and sign of the involved floating
    > point numbers.


    In particular, if the magnitude of 'x' is non-zero. ;-)

    -Arthur
    Arthur J. O'Dwyer, Oct 16, 2003
    #9
  10. gc

    gc Guest

    Andreas Kahari <> wrote in message > In this example, there will not be any difference to the result
    > if u+v is evaluated before/after w+x. The OP's concern is
    > without foundation.
    >


    Sorry for not making myself clear,
    I wanted to know whether the compiler is free to evaluate
    (u+v)-(w+x);

    as u+(v-w)-x; (i.e, add u to the result of v-w and then subtract x)
    or in any other order it finds suitable.



    Similarly, another question that arises is that whether is assured
    that the compiler will not interpret the the test (1+x>1) as (x>0), if
    x is double these two tests need not be the same
    gc, Oct 17, 2003
    #10
  11. gc

    gc Guest

    (Richard Bos) wrote in message
    > True, but it shouldn't matter at all in which order the two
    > sub-expressions are evaluated.


    So, if I understand you correctly, the subexpressions have to be
    calculated separately, i.e., the compiler cannot treat a+(b+c) and
    (a+b)+c the same way for floating point variables a,b,c. That was
    something I had doubts about, I wanted to know how much leeway the
    compiler had.

    > This:
    >
    > - add u and v; remember the result.
    > - add w and x; remember the result.
    > - subtract the second result from the first.
    >
    > should give the same answer as this:
    >
    > - add w and x; remember the result.
    > - add u and v; remember the result.
    > - subtract the first result from the second.
    >
    >
    > The problem only starts when you do things like
    >
    > a=b+c+d;
    >
    > because then, for floating point objects, (b+c)+d can give very
    > different results from b+(c+d). And indeed, the Standard prohibits
    > implementations from optimising that kind of expression too
    > enthusiastically. For example,
    >
    > a=x+y+z;
    > b=w+y+z;
    >
    > cannot be optimised into
    >
    > t=y+z
    > a=x+t;
    > b=w+t;
    >
    > because that might give different results. Contrariwise,
    >
    > a=y+z+x;
    > b=y+z+w;
    >
    > _can_ be optimised to
    >
    > t=y+z
    > a=t+x;
    > b=t+w;
    >
    >
    > But your example does not have this problem.
    >



    So, is x=a+b+c+d; considered treated the same as x=((a+b)+c)+d; i.e.,
    the summation is carried out from left to right?

    > Richard
    gc, Oct 17, 2003
    #11
  12. (gc) wrote:

    <snip>
    >
    >Sorry for not making myself clear,
    >I wanted to know whether the compiler is free to evaluate
    >(u+v)-(w+x);
    >
    >as u+(v-w)-x; (i.e, add u to the result of v-w and then subtract x)
    >or in any other order it finds suitable.


    Hm, I think Arthur already exlained it, but anyway:

    Yes, the compiler is free to do whatever, as long as the result is the
    same as if (w+x) was subtracted from (u+v).

    Otherwise parantheses were completely useless in algebraic expressions.

    >Similarly, another question that arises is that whether is assured
    >that the compiler will not interpret the the test (1+x>1) as (x>0), if
    >x is double these two tests need not be the same


    + has precedence over >; so, whatever code the compiler generates, it
    must behave as if 1+x was evaluated prior to >.

    Otherwise the operator precedence rules were completely useless.

    Regards
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Oct 17, 2003
    #12
  13. (gc) wrote:

    > (Richard Bos) wrote:

    <snip>
    >> And indeed, the Standard prohibits
    >> implementations from optimising that kind of expression too
    >> enthusiastically. For example,
    >>
    >> a=x+y+z;
    >> b=w+y+z;
    >>
    >> cannot be optimised into
    >>
    >> t=y+z
    >> a=x+t;
    >> b=w+t;
    >>
    >> because that might give different results. Contrariwise,
    >>
    >> a=y+z+x;
    >> b=y+z+w;
    >>
    >> _can_ be optimised to
    >>
    >> t=y+z
    >> a=t+x;
    >> b=t+w;
    >>
    >>
    >> But your example does not have this problem.
    >>

    >
    >
    >So, is x=a+b+c+d; considered treated the same as x=((a+b)+c)+d; i.e.,
    >the summation is carried out from left to right?


    Yes, all binary operators, except assignment operators, are evaluated
    from left to right.

    Regards
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Oct 17, 2003
    #13
  14. gc

    xarax Guest

    "Irrwahn Grausewitz" <> wrote in message
    news:...
    > (gc) wrote:

    /snip/
    > >Similarly, another question that arises is that whether is assured
    > >that the compiler will not interpret the the test (1+x>1) as (x>0), if
    > >x is double these two tests need not be the same

    >
    > + has precedence over >; so, whatever code the compiler generates, it
    > must behave as if 1+x was evaluated prior to >.
    >
    > Otherwise the operator precedence rules were completely useless.


    If "x" is an unsigned int with the value 0xffffffff, then you
    get different results between ((1+x)>1) versus (x > 0).

    OTOH, I cannot think of an integer example where
    (x>1) is different from (x>=0).

    Integer comparisons with constant zero are usually faster
    than non-zero compares, because most machines have fast
    compare-with-zero instructions. So a compiler may want
    to convert a non-zero compare to an equivalent zero-compare.
    xarax, Oct 17, 2003
    #14
  15. gc

    Joe Wright Guest

    xarax wrote:
    >
    > "Irrwahn Grausewitz" <> wrote in message
    > news:...
    > > (gc) wrote:

    > /snip/
    > > >Similarly, another question that arises is that whether is assured
    > > >that the compiler will not interpret the the test (1+x>1) as (x>0), if
    > > >x is double these two tests need not be the same

    > >
    > > + has precedence over >; so, whatever code the compiler generates, it
    > > must behave as if 1+x was evaluated prior to >.
    > >
    > > Otherwise the operator precedence rules were completely useless.

    >
    > If "x" is an unsigned int with the value 0xffffffff, then you
    > get different results between ((1+x)>1) versus (x > 0).
    >
    > OTOH, I cannot think of an integer example where
    > (x>1) is different from (x>=0).
    >

    If x is unsigned then (x >= 0) is always 1. There are two cases for (x >
    1) == 0.

    > Integer comparisons with constant zero are usually faster
    > than non-zero compares, because most machines have fast
    > compare-with-zero instructions. So a compiler may want
    > to convert a non-zero compare to an equivalent zero-compare.


    --
    Joe Wright http://www.jw-wright.com
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Oct 17, 2003
    #15
  16. "xarax" <> wrote:

    >"Irrwahn Grausewitz" <> wrote in message
    >news:...
    >> (gc) wrote:

    >/snip/
    >> >Similarly, another question that arises is that whether is assured
    >> >that the compiler will not interpret the the test (1+x>1) as (x>0), if
    >> >x is double these two tests need not be the same

    >>
    >> + has precedence over >; so, whatever code the compiler generates, it
    >> must behave as if 1+x was evaluated prior to >.
    >>
    >> Otherwise the operator precedence rules were completely useless.

    >
    >If "x" is an unsigned int with the value 0xffffffff, then you
    >get different results between ((1+x)>1) versus (x > 0).


    How does this affect operator precedence? A conforming implementation
    must generate code that, when executed, behave /AS IF/ the evaluation
    took place according to the requirements of the standard.

    You write ((1+x)>1), you get ((1+x)>1).

    >OTOH, I cannot think of an integer example where
    >(x>1) is different from (x>=0).
    >
    >Integer comparisons with constant zero are usually faster
    >than non-zero compares, because most machines have fast
    >compare-with-zero instructions. So a compiler may want
    >to convert a non-zero compare to an equivalent zero-compare.


    A conforming compiler may want (if a compiler can have desires at all)
    to grab the executable code from the rear side of a cornflakes box, as
    long as the results meet the requirements imposed by the standard.

    Regards
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Oct 17, 2003
    #16
  17. gc

    CBFalconer Guest

    Irrwahn Grausewitz wrote:
    > (gc) wrote:
    >
    > <snip>
    > >
    > > Sorry for not making myself clear, I wanted to know whether the
    > > compiler is free to evaluate
    > > (u+v)-(w+x);
    > > as u+(v-w)-x; (i.e, add u to the result of v-w and then subtract
    > > x) or in any other order it finds suitable.

    >
    > Hm, I think Arthur already exlained it, but anyway:
    >
    > Yes, the compiler is free to do whatever, as long as the result
    > is the same as if (w+x) was subtracted from (u+v).
    >
    > Otherwise parantheses were completely useless in algebraic
    > expressions.


    Not so, especially when dealing with floating point or possible
    overflows. The compiler is only free to rearrange things when it
    can detect that the results are identical. Note that it is
    perfectly allowable for an intermediate result to cause an
    overflow, even though the overall expression does not.

    Similarly an expression such as "bigvalue - 10 * littlevalue" is
    not the same as

    "bigvalue - littlevalue - littlevalue ..... - littlevalue"

    which _MIGHT_ well totally discard any effect from littlevalue.
    The cure is to use parentheses, as in:

    "bigvalue - (littlevalue + littlevalue ..... + littlevalue)"

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Oct 17, 2003
    #17
  18. On Fri, 17 Oct 2003, CBFalconer wrote:
    >
    > Irrwahn Grausewitz wrote:
    > > (gc) wrote:
    > > >
    > > > Sorry for not making myself clear, I wanted to know whether the
    > > > compiler is free to evaluate
    > > > (u+v)-(w+x);
    > > > as u+(v-w)-x; (i.e, add u to the result of v-w and then subtract
    > > > x) or in any other order it finds suitable.

    > >
    > > Hm, I think Arthur already exlained it, but anyway:
    > >
    > > Yes, the compiler is free to do whatever, as long as the result
    > > is the same as if (w+x) was subtracted from (u+v).
    > >
    > > Otherwise parantheses were completely useless in algebraic
    > > expressions.


    (s/were/would be/ in both this and the snipped part, BTW.
    And s/paran/paren/ .)


    > Not so, especially when dealing with floating point or possible
    > overflows. The compiler is only free to rearrange things when it
    > can detect that the results are identical.


    Yes, that's exactly what I and Irrwahn said. :) The "as-if"
    rule allows the compiler to produce whatever executable code it
    likes, as long as the result is the same as if (w+x) had been
    subtracted from (u+v).


    > Note that it is
    > perfectly allowable for an intermediate result to cause an
    > overflow, even though the overall expression does not.


    True. However, if the compiler can tell ahead-of-time that
    such an overflow will not occur, then it's free to optimize
    in that way. Heck, it can use the built-in "subtract A+B from
    C+D" FPU instruction, if it happens to have one.

    Oh, and something else for the OP's question: Many compilers
    will have a switch that allows you to turn off (or on) this
    strict compliance with ISO C as regards floating-point "as if"s.
    It is sometimes much faster, and occasionally much more
    accurate (!), to produce answers that *don't* follow the C
    standard. Consider my earlier example of

    double d = 3.14, e = 2.55;
    double f = d/e;
    printf("%d\n", d/e == f);

    On some compilers for x86, that will print different numbers
    (for appropriate values of 3.14 and 2.55), because the FPU
    registers are wider than the variables on the program's stack.
    So storing d/e into f loses precision, which is reflected in
    the output. To accurately reflect the standard (unless, as
    is likely, the standard leaves some loopholes for this sort
    of thing), you'd need to add an instruction to store d/e into
    a regular 'double' before the comparison, and that would slow
    down the program. So many compilers let you turn on and off
    some optimizations related to this sort of thing.

    HTH,
    -Arthur
    Arthur J. O'Dwyer, Oct 17, 2003
    #18
  19. CBFalconer <> wrote:

    >Irrwahn Grausewitz wrote:
    >> (gc) wrote:
    >>
    >> <snip>
    >> >
    >> > Sorry for not making myself clear, I wanted to know whether the
    >> > compiler is free to evaluate
    >> > (u+v)-(w+x);
    >> > as u+(v-w)-x; (i.e, add u to the result of v-w and then subtract
    >> > x) or in any other order it finds suitable.

    >>
    >> Hm, I think Arthur already exlained it, but anyway:
    >>
    >> Yes, the compiler is free to do whatever, as long as the result
    >> is the same as if (w+x) was subtracted from (u+v).
    >>
    >> Otherwise parantheses were completely useless in algebraic
    >> expressions.

    >
    >Not so, especially when dealing with floating point or possible
    >overflows. The compiler is only free to rearrange things when it
    >can detect that the results are identical.


    Well, that was sort of my point: if an implementation chooses to
    evaluate the expression (u+v)-(w+x) like u+(v-w)-x, without assuring
    that the result will be the expected one, why should one bother to
    write parantheses at all, as they were rendered useless by the (flawed)
    implementation.

    <absolutely correct notes snipped>

    Regards
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Oct 17, 2003
    #19
  20. gc

    P.J. Plauger Guest

    "Irrwahn Grausewitz" <> wrote in message
    news:...

    > >Not so, especially when dealing with floating point or possible
    > >overflows. The compiler is only free to rearrange things when it
    > >can detect that the results are identical.

    >
    > Well, that was sort of my point: if an implementation chooses to
    > evaluate the expression (u+v)-(w+x) like u+(v-w)-x, without assuring
    > that the result will be the expected one, why should one bother to
    > write parantheses at all, as they were rendered useless by the (flawed)
    > implementation.


    If a compiler generates incorrect code, why should one bother to write
    correct code at all, as it is rendered useless by the (flawed)
    implementation?

    And your point is...?

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
    P.J. Plauger, Oct 17, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. .Net Sports
    Replies:
    4
    Views:
    2,105
    Eliyahu Goldin
    Jun 29, 2005
  2. puzzlecracker
    Replies:
    0
    Views:
    438
    puzzlecracker
    Jan 25, 2006
  3. Rogue Noir
    Replies:
    6
    Views:
    2,413
    Arquebus257WeaMag
    Aug 2, 2003
  4. Bob Day
    Replies:
    1
    Views:
    306
    osmium
    Jul 11, 2003
  5. Mr. 4X
    Replies:
    5
    Views:
    300
    Kenny McCormack
    Jul 16, 2003
Loading...

Share This Page