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

 

[Jordan Abel]

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]

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]

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

 

[Sandeep]

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]

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.

 

[Dik T. Winter]

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

 

[Simon Biber]

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

 

[Skarmander]

Simon Biber wrote:

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]

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

 

[Keith Thompson]

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>

 

[Dik T. Winter]

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

 

[Christopher Benson-Manica]

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.

 

[Skarmander]

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]

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.

 

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

 

[Joe Wright]

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.

 

[Skarmander]

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]

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

 

[Jordan Abel]

Ben Pfaff said:


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]