Live data from Hacker News

Dennis Ritchie on the priorities of && || vs. == etc. (1982)

lysator.liu.se

11–20 of 178 posts

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#11
post #8

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

Also if you forget which is multiplication and which is addition, remember false is 0 and true is 1, then work it out from there: a * b is only nonzero if both of them are nonzero, so it's AND.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#12
post #8

Earlier quoted context omitted.

Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

Is there an intuition for this correspondence otherwise I don't think it's very helpful

a * b * c is only nonzero if all of a, b, c are nonzero. That's AND, and should be pretty intuitive.

a + b + c is nonzero if any of them are nonzero. (Remember each value is either 0 or 1.) So that's the intuition for OR.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#13
There's a niche language called Sail that has & and | act as both bitwise and boolean operators. It actually works really well and isn't confusing at all after the initial "this is different". There's no real downside because it is a modern strictly typed language unlike C.

On the other hand I don't know if there's a real upside either. It's not very difficult to use && and || and it serves as extra documentation, and everyone is used to it by now.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#14
post #8

Earlier quoted context omitted.

Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

Is there an intuition for this correspondence otherwise I don't think it's very helpful

this is the notation used in the chapters about boolean algebra in my digital design course. I think it's pretty neat. I honestly never looked into operator precedence in any language enough to notice the relation.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#15

There's a niche language called Sail that has & and | act as both bitwise and boolean operators. It actually works really well and isn't confusing at all after the initial "this is different". There's no real downside because it is a modern strictly typed language unlike C. On the other hand I don't know if there's a real upside either. It's not very difficult to use && and || and it serves as extra documentation, an…

Well in C-derived languages && and || will short-circuit the evaluation whereas & and | will not.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#16

Earlier quoted context omitted.

Is there an intuition for this correspondence otherwise I don't think it's very helpful

a * b * c is only nonzero if all of a, b, c are nonzero. That's AND, and should be pretty intuitive. a + b + c is nonzero if any of them are nonzero. (Remember each value is either 0 or 1.) So that's the intuition for OR.

a+b+c is nonzero if any of a or b or c are nonzero.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#17
post #8

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

1+1=1? My maths education was a long time ago, but I triple checked with my calculator, and I'm uncertain this is quite right.

My own mnemonic: SAXO. Shift, And, Xor, Or. (Like a real Saxo, it's fun to go a bit faster like this, but you do have to trust everybody involved, because any accident is probably going to end up badly for you.)

And now you know the bitwise precedence as well! And this ordering actually works out tidily for common operations: "x=a>n&m"; "x=x&~ma|a(Main annoying thing: a lot of compilers, even popular ones such as clang and gcc, don't actually seem to know what the precedence rules actually are, and generate warnings asking you to clarify. Presumably the authors didn't realise that C has an ISO standard, that can be consulted to answer this question? Very surprising.)

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#18
post #8

Earlier quoted context omitted.

Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

Is there an intuition for this correspondence otherwise I don't think it's very helpful

Conjunction used to be called logical product, and disjunction logical sum, for the reason the other commenters pointed out.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#19

There's a niche language called Sail that has & and | act as both bitwise and boolean operators. It actually works really well and isn't confusing at all after the initial "this is different". There's no real downside because it is a modern strictly typed language unlike C. On the other hand I don't know if there's a real upside either. It's not very difficult to use && and || and it serves as extra documentation, an…

Forths often use -1 as TRUE so logical and bitwise operators coincide.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#20

Earlier quoted context omitted.

a * b * c is only nonzero if all of a, b, c are nonzero. That's AND, and should be pretty intuitive. a + b + c is nonzero if any of them are nonzero. (Remember each value is either 0 or 1.) So that's the intuition for OR.

a+b+c is nonzero if any of a or b or c are nonzero.

Yeah I just added that. I was hesitant initially cause you have to also note they're nonnegative, and that you're treating them like real numbers rather than mod 2.
Post reply on HN