Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Understanding "logical OR" and "logical AND" in programming languages
Parent
Understanding "logical OR" and "logical AND" in programming languages
Many programming languages either have keywords like or
and and
used for logic, or equivalent operators such as ||
or &&
- which are referred to as "logical or" and "logical and" respectively in the language documentation. However, these tools don't seem to work in a natural or expected way for many beginners. Which is to say: "translating" an English sentence into code, using or
or ||
to represent the English word "or", etc., commonly causes errors or gives the wrong result.
Why is this? What are the semantics of these operators, and how is that different from a natural-language understanding? And why are they called "logical"? (Are there other kinds?)
Post
The explanation is that human languages are fundamentally confusing on this, but, because humans tend to be somewhat blind to complexities in systems that they've literally been the only thing they've known since before they have memory (you tend to learn to speak well before persists-into-adulthood memories). So they think and+or is less complex than it is.
Some trivial jokes that highlight this:
Jane asks Joe to go to the store to buy a loaf of bread. Oh, and if they have eggs, buy 10.
Joe returns with 10 loaves of bread. Jane, exasperated, asks Joe what the heck he thinks he's doing. Joe answer: "... they had eggs".
Alex asks Sasha if she wants her cake with whipped cream or without whipped cream.
Sasha says: "Yes".
More generally, the principle at work is that you need parentheses in order to determine order of precedence when you infix your ands and ors. Here's a simple truth table:
A or B and C
can mean different things depending on how you resolve it (how you determine the precedence there). It can mean:
- A or (B and C)
- (A or B) and C
For example:
If it rains or the sprinkler system is on, and the swimming pool isn't covered, the water level inside it will be raised. (this is (A OR B) and C
where A is rain, B is sprinkler, C is pool cover).
if it rains or I'm standing over the sprinkler and the sprinkler is on, I will get wet. (this is A or (B and C)
where A is rain, B is standing over the sprinkler, C is the sprinkler is on.
So why isn't this confusing to you?
Because of context. You are visualizing the situation. Linguistically there is no difference here. It is not possible to tell. If I actually meant this hard to imagine bizarre scenario, where you get wet only if:
- It is raining or you are standing over the sprinkler.
- AND, regardless, the sprinkler must be on.
(i.e. (A or B) and C
), then I can say the exact same sentence and it can be interpreted that way equally validly.
The reason you don't interpret it that was is because you're not an idiot, and you have an imagination: You are seeing the sprinkler, standing outside, in the rain, and so on. You know which of the two linguistically equally likely explanations is the obvious intent of the speaker. But this requires vast amounts of context, and, is ambiguous - context cannot always make clear which one is clearly intended; ambiguity is generally hated in programming languages for fairly obvious reasons.
So, in programming languages, parentheses are used, and those new to coding find it difficult. Because it is difficult and that 'applying the context to figure out what was intended' is something they've been doing since they were 3 years old, so it's difficult to realize you're even doing that.
There are exotic solutions of course. such as using postfix syntax. This:
- A B C and or
- A B or C and
(That's RPN - Reverse Polish Notation. A
pushes A on the stack, B
pushes B on the stack, or
pops 2 values off the stack and applies the OR operation on them, then pushes that on the stack. The result of the calculation is that one thing is on the stack and that is your answer).
isn't ambiguous and yet does not require parentheses. But, while I'm not a psychologist, I find it natural that it is easier to understand operations if the operands are as close to the operator as possible. This isn't always the case with RPN. That's presumably why most languages don't go for this (stuff like PostScript and Forth - stack based languages, really are written like this, though!)
1 comment thread