Skip to content

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 (== != < > <= >=) produce true/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 a true/false answer. 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 * 4 is 14, not 20, 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/or let 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 = 10 stores
  • (You met this in P1.2.)
  • == is comparison: "are these two values equal?" score == 10 asks a question and produces true or false. 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.

  1. Print a few arithmetic expressions, including 2 + 3 * 4. Predict each result first, then run. Add parentheses to change 2 + 3 * 4 into 20 and confirm.
  2. Print several comparisons (7 > 2, 5 == 5, 5 != 5) and confirm each shows true or false.
  3. Store a comparison in a variable: var passed := score >= 60 (set score first). Print passed.
  4. Demonstrate = vs ==: set var x := 5, then on one line x = 9 (assignment) and print(x) (shows 9), and on another print(x == 9) (comparison, shows true). Say out loud which one changed x and 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 booltrue 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:

var can_buy := gold >= price and has_free_slot

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.