Precedence of Logical Operators

[August Karlstrom]

Hi,

Can someone explain the reason for the warning from GCC below:

<shell-session>

$ cat test.c
#include <stdbool.h>

bool a, b, c, d;
int x, y, z, u;

int main(void)
{
d = a || b && c;
u = x + y * z;
return 0;
}

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Jordan Abel]

On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

Hi,

Can someone explain the reason for the warning from GCC below:

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)

Logical operators are easier for people to get confused about because
they are less familiar.

[osmium]

"August Karlstrom" writes:

Can someone explain the reason for the warning from GCC below:

<shell-session>

$ cat test.c
#include <stdbool.h>

bool a, b, c, d;
int x, y, z, u;

int main(void)
{
d = a || b && c;
u = x + y * z;
return 0;
}

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)

"A foolish consistency is the hobgoblin of little minds" - Emerson

[August Karlstrom]

Jordan Abel wrote:

On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

Hi,

Can someone explain the reason for the warning from GCC below:

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)

Logical operators are easier for people to get confused about because
they are less familiar.

What about

d = a == b && c;

then? GCC issues no warning with the statement above. In Pascal

d := a = b AND c

means

d := a = (b AND c)
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Sandeep]

August Karlstrom wrote:

Hi,

Can someone explain the reason for the warning from GCC below:

<shell-session>

$ cat test.c
#include <stdbool.h>

bool a, b, c, d;
int x, y, z, u;

int main(void)
{
d = a || b && c;
u = x + y * z;
return 0;
}

$ gcc -Wall test.c
test.c: In function 'main':
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)

It _may_ be beacuse of the fact that while evaluating an expression
involving logical operator, compilers optimize the code so that even if
one of the condition evaluates to "true/false" (depending on the
complete statement) , the remaining expressions are _not_ evaluated.
Eg:
if( a || b && c && d && e)

here if "a" evaluates to true, the other expression might not be
evaluated. This can sometime lead to unexpected results if parentheses
are not properly provided.

[Keith Thompson]

August Karlstrom <fu********@comhem.se> writes:

Jordan Abel wrote:

On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

Can someone explain the reason for the warning from GCC below:

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z'
as well? (which would be absurd)

Logical operators are easier for people to get confused about because
they are less familiar.

What about

d = a == b && c;

then? GCC issues no warning with the statement above. In Pascal

d := a = b AND c

means

d := a = (b AND c)

gcc, like any compiler, issues whatever warnings its authors thought
worth issuing (and spent the time to implement). There's no
requirement that they be consistent, as long as the compiler issues
all diagnostics required by the standard.

If you want to discuss the choices the authors made, try gnu.gcc.bug
or gnu.gcc.help.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dik T. Winter]

In article <sl********************@random.yi.org> Jordan Abel <jm****@purdue.edu> writes:

On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

Hi,
Can someone explain the reason for the warning from GCC below:

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)

Logical operators are easier for people to get confused about because
they are less familiar.

The more so because in mathematics there is *no* precedence between and and
or. But there is between + and * (although many people even get that wrong.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Simon Biber]

Dik T. Winter wrote:

In article <sl********************@random.yi.org> Jordan Abel <jm****@purdue.edu> writes:

> On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

> > Hi,
> > Can someone explain the reason for the warning from GCC below:
> >
> > $ gcc -Wall test.c
> > test.c: In function ‘main’:
> > test.c:8: warning: suggest parentheses around && within ||
> >
> > </shell-session>
> >
> > For sake of consistency, why not suggest parentheses around `y * z' as
> > well? (which would be absurd)

>
> Logical operators are easier for people to get confused about because
> they are less familiar.

The more so because in mathematics there is *no* precedence between and and
or. But there is between + and * (although many people even get that wrong.)

When I studied Boolean algebra, we certainly did consider /\ (and) to
have greater precedence than \/ (or).

--
Simon.

[Skarmander]

Simon Biber wrote:
<snip>

When I studied Boolean algebra, we certainly did consider /\ (and) to
have greater precedence than \/ (or).

This is common in books and courses oriented specifically towards
computer science, because programming languages do it (not all, but many).

In mathematics generally this is virtually unheard of, because
conjunction and disjunction are each other's duals, and assigning one
higher priority than the other seems unnatural.

S.

[August Karlstrom]

Dik T. Winter wrote:

In article <sl********************@random.yi.org> Jordan Abel <jm****@purdue.edu> writes:

> On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

> > Hi,
> > Can someone explain the reason for the warning from GCC below:
> >
> > $ gcc -Wall test.c
> > test.c: In function ‘main’:
> > test.c:8: warning: suggest parentheses around && within ||
> >
> > </shell-session>
> >
> > For sake of consistency, why not suggest parentheses around `y * z' as
> > well? (which would be absurd)

>
> Logical operators are easier for people to get confused about because
> they are less familiar.

The more so because in mathematics there is *no* precedence between and and
or. But there is between + and * (although many people even get that wrong.)

OK, that's probably a good reason for not assuming any particular
precedence. In Ada `and' and `or' have the same precedence. In all
other common imperative languages I have checked "and" has higher
precedence than "or". Oberon even uses & for "and" and OR for "or" to
make "and" stand out less than "or" and hence emphasize the difference
in precedence.
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Keith Thompson]

August Karlstrom <fu********@comhem.se> writes:
[...]

OK, that's probably a good reason for not assuming any particular
precedence. In Ada `and' and `or' have the same precedence. In all
other common imperative languages I have checked "and" has higher
precedence than "or". Oberon even uses & for "and" and OR for "or" to
make "and" stand out less than "or" and hence emphasize the difference
in precedence.

<OT>
And in Ada, a special rule requires parentheses when "and" and "or"
are mixed in the same expression, so the potentially ambiguous
expression (x or y an z) is illegal.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dik T. Winter]

In article <43***********************@news.optusnet.com.au> Simon Biber <ne**@ralmin.cc> writes:
....

The more so because in mathematics there is *no* precedence between and
and or. But there is between + and * (although many people even get
that wrong.)

When I studied Boolean algebra, we certainly did consider /\ (and) to
have greater precedence than \/ (or).

The distinction between /\ and \/ is artificial. Given a Boolean algebra,
when you interchange the two operators and the names of (in Bell's
terminology) Z and I, you have again a Boolean algebra. So in standard
mathematics there is no precedence. You have only two operators, a set
and a collection of axioms those operators do satisfy.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Christopher Benson-Manica]

Jordan Abel <jm****@purdue.edu> wrote:

Logical operators are easier for people to get confused about because
they are less familiar.

I know from experience that even people who should know better (such
as my boss) may not be aware of the precedence of boolean operators.
He once pointed out a "bug" in my code that was in fact correct, and I
had to fall back to my copy of K&R2 to prove it to him.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Skarmander]

Christopher Benson-Manica wrote:

Jordan Abel <jm****@purdue.edu> wrote:

Logical operators are easier for people to get confused about because
they are less familiar.

I know from experience that even people who should know better (such
as my boss) may not be aware of the precedence of boolean operators.
He once pointed out a "bug" in my code that was in fact correct, and I
had to fall back to my copy of K&R2 to prove it to him.

I had a teacher do that to me once. He deducted points for my use of
"%d" in a printf statement for printing an int, since (true story) he
didn't know "%d" existed. He was used to "%i". (In case you're
wondering: the code was delivered on paper for tests, hand-written, no
editors used. You'd even get deducted points for syntax errors.) I had
to pull out the book *he* was supposed to be teaching from.

What made this odd was that this was the only error he could find. He
didn't bother to check if the guy who got everything else right might
have been right about a printf specifier, too.

S.

[Ben Pfaff]

Skarmander <in*****@dontmailme.com> writes:

I had a teacher do that to me once. He deducted points for my use of
"%d" in a printf statement for printing an int, since (true story) he
didn't know "%d" existed. He was used to "%i". (In case you're
wondering: the code was delivered on paper for tests, hand-written, no
editors used. You'd even get deducted points for syntax errors.) I had
to pull out the book *he* was supposed to be teaching from.

I once had a teacher deduct points for using "n * (n + 1) / 2" as
the sum of 1...n, because she didn't know that it was a correct
formula. I had to demonstrate to her and the entire class that
it was correct.
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

[Richard Heathfield]

Ben Pfaff said:

I once had a teacher deduct points for using "n * (n + 1) / 2" as
the sum of 1...n, because she didn't know that it was a correct
formula. I had to demonstrate to her and the entire class that
it was correct.

Precisely the same thing happened to me. Instead of saying "okay okay, so
now go write the thing again using a loop", Lorraine (surname mercifully
long-forgotten) tried to get clever, and told us to write the sum of
1...n*n - and I'm sure you can imagine how that went. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Joe Wright]

Dik T. Winter wrote:

In article <sl********************@random.yi.org> Jordan Abel <jm****@purdue.edu> writes:

> On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:

> > Hi,
> > Can someone explain the reason for the warning from GCC below:
> >
> > $ gcc -Wall test.c
> > test.c: In function ‘main’:
> > test.c:8: warning: suggest parentheses around && within ||
> >
> > </shell-session>
> >
> > For sake of consistency, why not suggest parentheses around `y * z' as
> > well? (which would be absurd)

>
> Logical operators are easier for people to get confused about because
> they are less familiar.

The more so because in mathematics there is *no* precedence between and and
or. But there is between + and * (although many people even get that wrong.)

Way in the mid last century when I was learning computer logic for the
first time Boolean algebra expressions looked like 'a * b + c' which
meant precisely that '*' was 'and' and '+' was 'or'. Did we all go to
different schools together, or what?

This was 1962 at Philco Corporation. The '*' did have precedence and the
above from was equivalent to '(a * b) + c'. Our instructor explained the
similarities between 'and' and 'mult' and between 'or' and 'add' but
they are now lost in the fogs of time.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Skarmander]

Joe Wright wrote:

Dik T. Winter wrote:

In article <sl********************@random.yi.org> Jordan Abel
<jm****@purdue.edu> writes:

> On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:
> > Hi,
> > Can someone explain the reason for the warning from GCC below:
> >
> > $ gcc -Wall test.c
> > test.c: In function ‘main’:
> > test.c:8: warning: suggest parentheses around && within ||
> >
> > </shell-session>
> >
> > For sake of consistency, why not suggest parentheses around `y * z' as > > well? (which would be absurd)

> > Logical operators are easier for people to get confused about

because

> they are less familiar.

The more so because in mathematics there is *no* precedence between
and and
or. But there is between + and * (although many people even get that
wrong.)

Way in the mid last century when I was learning computer logic for the
first time Boolean algebra expressions looked like 'a * b + c' which
meant precisely that '*' was 'and' and '+' was 'or'. Did we all go to
different schools together, or what?

It's likely, although I did see this when I learned Boolean logic. Note
that '+' is *not* 'or', since 1 + 1 = 10, while 1 or 1 = 1. It makes
more sense to "equate" '+' with 'xor' (IIRC, the notation is still used
sometimes in electrical engineering). Note that half-adders are built
with an 'and' and an 'xor' gate.
This was 1962 at Philco Corporation. The '*' did have precedence and the
above from was equivalent to '(a * b) + c'. Our instructor explained the
similarities between 'and' and 'mult' and between 'or' and 'add' but
they are now lost in the fogs of time.

The precedence here is added by analogy: '*' has precedence over '+',
'and' and 'or' are similar to '*' and '+', ergo.

Of course it's not *wrong*; you can add precedence in any way you like.
This convention is simply not used in mathematics, because it's
artificial compared to letting '*' take precedence over '+' ('*' is
typically defined in terms of '+', so it's a "higher" operator).

De Morgan's laws illustrate it very well:

a && b == !(!a || !b)
a || b == !(!a && !b)

Or if you prefer

!(a && b) == !a || !b
!(a || b) == !a && !b

There is very compelling reason to treat 'and' and 'or' equally in
algebraic theory. Adding precedence, as many programming languages do,
has the practical advantage of write down some expressions with less
parentheses, but it's simply not a universal convention.

S.

[Michael Mair]

Joe Wright wrote:

Dik T. Winter wrote:

In article <sl********************@random.yi.org> Jordan Abel
<jm****@purdue.edu> writes:

> On 2005-11-20, August Karlstrom <fu********@comhem.se> wrote:
> > Hi,
> > Can someone explain the reason for the warning from GCC below:
> >
> > $ gcc -Wall test.c
> > test.c: In function ‘main’:
> > test.c:8: warning: suggest parentheses around && within ||
> >
> > </shell-session>
> >
> > For sake of consistency, why not suggest parentheses around `y *

z' as > > well? (which would be absurd)

> > Logical operators are easier for people to get confused about

because

> they are less familiar.

The more so because in mathematics there is *no* precedence between
and and
or. But there is between + and * (although many people even get that
wrong.)

Way in the mid last century when I was learning computer logic for the
first time Boolean algebra expressions looked like 'a * b + c' which
meant precisely that '*' was 'and' and '+' was 'or'. Did we all go to
different schools together, or what?

This was 1962 at Philco Corporation. The '*' did have precedence and the
above from was equivalent to '(a * b) + c'. Our instructor explained the
similarities between 'and' and 'mult' and between 'or' and 'add' but
they are now lost in the fogs of time.

Hmmm, I certainly remember hearing about the precedence of and over
or and intersection over union in school and later on in university
but this may of course have been defined so for convenience.
And this was within the last fifteen years...
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Jordan Abel]

On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote:

Ben Pfaff said:

I once had a teacher deduct points for using "n * (n + 1) / 2" as
the sum of 1...n, because she didn't know that it was a correct
formula. I had to demonstrate to her and the entire class that
it was correct.

Precisely the same thing happened to me. Instead of saying "okay okay, so
now go write the thing again using a loop", Lorraine (surname mercifully
long-forgotten) tried to get clever, and told us to write the sum of
1...n*n - and I'm sure you can imagine how that went. :-)

Not once did she stop to think "Well if he had a formula for that, maybe
he'll manage to pull another one out"?

I did the same thing with the fibonacci series when we were supposed to
use recursion. [I ended up turning in a recursive solution that used a
small cache to alleviate the exponential growth of a naive recursive
fibonacci solution]

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Skarmander <in*****@dontmailme.com> writes:

I had a teacher do that to me once. He deducted points for my use of
"%d" in a printf statement for printing an int, since (true story) he
didn't know "%d" existed. He was used to "%i". (In case you're
wondering: the code was delivered on paper for tests, hand-written, no
editors used. You'd even get deducted points for syntax errors.) I had
to pull out the book *he* was supposed to be teaching from.

I once had a teacher deduct points for using "n * (n + 1) / 2" as
the sum of 1...n, because she didn't know that it was a correct
formula. I had to demonstrate to her and the entire class that
it was correct.

Suppose you're using a system where int is 16 bits, and n==255. The
intermediate expression 255*256 yields 65280, which overflows, though
the final result is 32640, which doesn't. The formula invokes
undefined behavior, whereas adding the numbers 1..n individually
wouldn't. Similar examples exist for other sizes of int.

A workaround is to divide either n or n+1, whichever is even, by 2
before doing the multiplication:

n%2==0 ? (n/2) * (n+1) : n * (n+1)/2

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Skarmander]

Skarmander wrote:

Adding precedence, as many programming languages do, has the
practical advantage of write down some expressions with less
parentheses, but it's simply not a universal convention.

Wow, that sentence seriously no grammar. I trust everyone still got the
gist of it...

S.

[Old Wolf]

Ben Pfaff wrote:

I once had a teacher deduct points for using "n * (n + 1) / 2" as
the sum of 1...n, because she didn't know that it was a correct
formula. I had to demonstrate to her and the entire class that
it was correct.

Oh my gauss.

In primary school, a (very blonde) teacher posed an equation
similar to this:

4 * 3 + 2 + 9 - 4 + 17 * 2 + 3 * 0

and asserted that the answer was 0, because anything times zero
is zero. When I demonstrated otherwise on my calculator, she said
that my calculator must be wrong.

[August Karlstrom]

Old Wolf wrote:

Ben Pfaff wrote:

I once had a teacher deduct points for using "n * (n + 1) / 2" as
the sum of 1...n, because she didn't know that it was a correct
formula. I had to demonstrate to her and the entire class that
it was correct.

Oh my gauss.

In primary school, a (very blonde) teacher posed an equation

I suppose you mean "expression" (I'm currently in nitpicking mode ;-)
similar to this:

4 * 3 + 2 + 9 - 4 + 17 * 2 + 3 * 0

and asserted that the answer was 0, because anything times zero
is zero. When I demonstrated otherwise on my calculator, she said
that my calculator must be wrong.

August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Malcolm]

"August Karlstrom" <fu********@comhem.se> wrote

#include <stdbool.h>

bool a, b, c, d;
int x, y, z, u;

int main(void)
{
d = a || b && c; gibberish u = x + y * z; sensible expression anyone with a basic understanding of mathematical
conventions can read return 0;
}

$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:8: warning: suggest parentheses around && within ||

</shell-session>

For sake of consistency, why not suggest parentheses around `y * z' as
well? (which would be absurd)

If you submit gibberish code to the compiler you should get warnings out.
Nothing wrong with that.

[August Karlstrom]

Malcolm wrote:

"August Karlstrom" <fu********@comhem.se> wrote

#include <stdbool.h>

bool a, b, c, d;
int x, y, z, u;

int main(void)
{
d = a || b && c;

gibberish

u = x + y * z;

sensible expression anyone with a basic understanding of mathematical
conventions can read

That's a ridiculous motivation for using extra parentheses. As we all
know, there are numerous examples of where C does not follow
mathematical conventions. In mathematics `x = x + 1' is an equation with
no solutions and 1/2 does not equal 0 etc. In C the symbols && and ||
are different from ∧ and ∨ and they use short-circuit evaluation, so
they are already quite different from their mathematical counterpart.

Moreover, in basically all imperative languages I have looked at (ADA is
an exception), `and' has higher precedence than `or', so my example
above is certainly not "gibberish". It's rather a matter of personal
preference.
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.