P1.4 — Operators & Expressions¶
What you'll learn
- What an expression is: a piece of code that produces a value.
- Arithmetic operators (
+ - * /) and that comparisons (== != < > <= >=) producetrue/false. - Logical operators (
and,or,not) for combining true/false values. - The critical difference between
=(assign) and==(compare).
How it applies
- Comparisons are how a program asks questions.
health <= 0,score > best,name == "Vex"each produce atrue/falseanswer. The next chapter's decisions run entirely on these answers, so getting comparisons right is what makes the program react correctly. =versus==is the most common beginner bug. One puts a value into a variable; the other asks whether two values are equal. Mixing them up either changes data you meant to test, or asks a question you meant to be an assignment. Knowing the two symbols apart prevents a whole class of confusing errors.- Order of operations is real.
2 + 3 * 4is14, not20, because*happens before+— just like in math. When in doubt, parentheses make the order explicit and the intent obvious. - Combining conditions models real rules. "Alive and has a key," "low health or poisoned" —
and/orlet a program express the actual rule instead of a clumsy chain of separate checks.
Concepts¶
Expressions: code that produces a value¶
An expression is any piece of code that the computer evaluates down to a single value. 2 + 3 is
an expression; it produces 5. score is an expression; it produces whatever is stored in score.
"Game " + "Over" is an expression; it produces "Game Over". Wherever a value is expected — the
right side of an assignment, inside a print, later inside a decision — you can put an expression, and
the computer reduces it to its value first.
Arithmetic operators¶
The math operators work as you expect:
print(2 + 3) # 5 addition
print(10 - 4) # 6 subtraction
print(6 * 7) # 42 multiplication
print(20 / 5) # 4 division
They follow the usual order of operations — multiplication and division before addition and
subtraction — so 2 + 3 * 4 is 14. Parentheses force a different order and, even when not strictly
needed, make intent clear: (2 + 3) * 4 is 20.
Comparison operators produce true/false¶
A comparison asks a yes/no question about two values and produces a bool (P1.3):
print(5 > 3) # true
print(5 < 3) # false
print(10 == 10) # true — "is equal to?"
print(10 != 7) # true — "is not equal to?"
print(4 >= 4) # true — "greater than or equal to?"
The result is a real value you can store: var can_afford := gold >= price puts true or false
into can_afford. This is the bridge to decisions: a comparison turns "is the player out of health?"
into a true/false the program can act on.
= versus ==¶
These two are different and the confusion between them is the classic beginner trap:
=is assignment: "put the right value into the variable on the left."score = 10stores- (You met this in P1.2.)
==is comparison: "are these two values equal?"score == 10asks a question and producestrueorfalse. It changes nothing.
var score := 5
score = 10 # assignment: score now holds 10
print(score == 10) # comparison: asks "is score equal to 10?" → true
print(score == 99) # → false
One equals sign changes a variable; two equals signs test a value. Reading them aloud helps: = is
"becomes," == is "is equal to?"
Logical operators: and, or, not¶
These combine true/false values into a single true/false:
and— true only if both sides are true.or— true if either side is true.not— flips true to false and false to true.
var alive := true
var has_key := false
print(alive and has_key) # false — needs both; has_key is false
print(alive or has_key) # true — either is enough; alive is true
print(not alive) # false — flips true
Example
Build one meaningful condition from smaller pieces:
var health := 8
var max_health := 100
var is_poisoned := true
var in_danger := health < (max_health * 0.2) or is_poisoned
print(in_danger) # true
Read it inside-out: max_health * 0.2 is 20; health < 20 is true (8 is less than 20); then
true or is_poisoned is true. The whole expression collapses to one bool, true, stored in
in_danger. That single value is exactly what a decision (next chapter) needs. Note == would be
wrong here — you are comparing magnitudes and combining facts, not assigning anything.
Walkthrough¶
Use your P1.1 script setup.
- Print a few arithmetic expressions, including
2 + 3 * 4. Predict each result first, then run. Add parentheses to change2 + 3 * 4into20and confirm. - Print several comparisons (
7 > 2,5 == 5,5 != 5) and confirm each showstrueorfalse. - Store a comparison in a variable:
var passed := score >= 60(setscorefirst). Printpassed. - Demonstrate
=vs==: setvar x := 5, then on one linex = 9(assignment) andprint(x)(shows9), and on anotherprint(x == 9)(comparison, showstrue). Say out loud which one changedxand which one asked a question.
Optional sanity check
Combine two conditions with and, then the same two with or, using values where they differ
(one true, one false). and gives false, or gives true. Flip one value and watch each result
change. Seeing and/or react to their inputs is what makes the next chapter's decisions feel
predictable rather than magic.
Self-check quiz¶
Q1 — What does a comparison like score >= 60 produce?
A. It sets score to 60.
B. A true/false value answering whether score is at least 60.
C. The number 60.
D. An error unless score is exactly 60.
Reveal answer
B. A comparison evaluates to a bool — true or false — reporting whether the relation
holds; it changes nothing. A confuses it with assignment (=). C and D misread what a comparison
returns; it is a yes/no answer, not a number, and it works for any value of score.
Q2 — What is the difference between = and ==?
A. They are the same; the extra = is optional.
B. = puts a value into a variable (assignment); == asks whether two values are equal (comparison) and changes nothing.
C. = compares; == assigns.
D. == only works on numbers.
Reveal answer
B. One equals sign assigns ("becomes"); two equals signs compare ("is equal to?"). A is the
exact misconception to avoid — they are not interchangeable. C reverses them. D invents a
restriction (== compares text and bools too).
Q3 — var ok := alive and has_key. When is ok true?
A. When either alive or has_key is true.
B. Only when both alive and has_key are true.
C. Always.
D. Only when both are false.
Reveal answer
B. and is true only if both sides are true. A describes or. C and D are wrong — ok
depends on its inputs, and and specifically requires both to be true, not both false.
Integration question¶
Q4 — open
A shop should let a purchase happen only when the player has enough gold and has a free inventory
slot. A teammate writes var can_buy = gold = price, intending "the player can buy if gold is at
least the price." Two things are wrong with that line. Identify both — one about the right operator
for "at least," one about = versus == — and write a corrected line that also requires a free
slot (assume a variable has_free_slot).
Reveal expected answer
Problem 1 — wrong comparison operator. "At least the price" means greater than or equal to,
which is >=, not equality. gold == price (even if the operator were right) would only allow
the purchase when gold exactly equals the price, not when it is more. Problem 2 — = instead
of == (and a doubled assignment). The line gold = price is an assignment — it would
overwrite the player's gold with the price, changing their data instead of asking a question; and
chaining it as can_buy = gold = price compounds the mistake. The intent was a comparison. The
corrected condition compares with >= and combines the two requirements with and:
This stores a single true/false in can_buy: true only when gold is at least the price
and a slot is free. The line changes no existing data — it asks a question and records the
answer, which is exactly what a condition should do, and exactly what the next chapter's if
will consume.