Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > parenthesis

Reply
Thread Tools

parenthesis

 
 
gc
Guest
Posts: n/a
 
      10-17-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) (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

 
Reply With Quote
 
 
 
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      10-17-2003
(E-Mail Removed) (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
((E-Mail Removed))
 
Reply With Quote
 
 
 
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      10-17-2003
(E-Mail Removed) (gc) wrote:

>(E-Mail Removed) (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
((E-Mail Removed))
 
Reply With Quote
 
xarax
Guest
Posts: n/a
 
      10-17-2003
"Irrwahn Grausewitz" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (E-Mail Removed) (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.




 
Reply With Quote
 
Joe Wright
Guest
Posts: n/a
 
      10-17-2003
xarax wrote:
>
> "Irrwahn Grausewitz" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > (E-Mail Removed) (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 ---
 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      10-17-2003
"xarax" <(E-Mail Removed)> wrote:

>"Irrwahn Grausewitz" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>> (E-Mail Removed) (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
((E-Mail Removed))
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      10-17-2003
Irrwahn Grausewitz wrote:
> (E-Mail Removed) (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 ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      10-17-2003

On Fri, 17 Oct 2003, CBFalconer wrote:
>
> Irrwahn Grausewitz wrote:
> > (E-Mail Removed) (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
 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      10-17-2003
CBFalconer <(E-Mail Removed)> wrote:

>Irrwahn Grausewitz wrote:
>> (E-Mail Removed) (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
((E-Mail Removed))
 
Reply With Quote
 
P.J. Plauger
Guest
Posts: n/a
 
      10-17-2003
"Irrwahn Grausewitz" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> >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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
regular expression to insert spaces around parenthesis puzzlecracker Java 0 01-25-2006 07:31 PM
")" expected error when there's supppose to be only 1 set of parenthesis .Net Sports ASP .Net 4 06-29-2005 06:33 PM
bracket or parenthesis number in Documents Larry Smith Computer Support 3 02-15-2005 01:19 AM
Free IDE with Parenthesis Matching? Rogue Noir C++ 6 08-02-2003 06:42 PM
Re: Automatic parenthesis for complex calculation Bob Day C Programming 1 07-11-2003 01:58 PM



Advertisments