Lesson 10: Nested Conditionals & the Robot

Warm-Up

Movie tickets: children under 10 pay $6; everyone else pays $9, except seniors 65+ who pay $7. A programmer writes:

IF (age < 10)
{
    price ← 6
}
ELSE
{
    IF (age ≥ 65)
    {
        price ← 7
    }
    ELSE
    {
        price ← 9
    }
}

Try age = 8: first condition true → price 6, inner code never touched. Age = 70: first false → into ELSE → 70 ≥ 65 true → price 7. Age = 30: false, then false → price 9. Three ages, three paths, each visiting only the tests along its route.

That's nesting: conditionals inside conditionals, where reaching an inner test requires taking a particular outer branch. Every trace error in nested code comes from forgetting that geography.

Core Concept

Nested conditionals: the geography of branches

A nested conditional places an IF (or IF/ELSE) inside a branch of another. Two consequences:

1. Inner conditions are only evaluated if their outer branch runs. In the warm-up, age ≥ 65 is never even checked for an 8-year-old.
2. Exactly one leaf runs. However deep the nesting, one path from the top to one innermost block executes; everything else is skipped.

Tracing discipline: at each condition, write T or F, follow that branch only, and physically cross out the branch not taken. The exam's wrong answers are exactly the values produced by wandering into crossed-out territory.

Order matters in multi-way chains

Consider grading: 90+ → A, 80+ → B, below 80 → C. This version is broken:

IF (score ≥ 80)
{
    grade ← "B"
}
ELSE
{
    IF (score ≥ 90)          ← unreachable!
    {
        grade ← "A"
    }
    ...
}

A 95 hits score ≥ 80 first → grade B. The ≥ 90 test lives inside the ELSE — reachable only when score < 80, where it can never be true. When conditions overlap, test the most specific/extreme first. The exam loves handing you a broken chain and asking "for which input does this misbehave?" — the answer is an input satisfying a later (more specific) condition that gets captured by an earlier (broader) one.

The AP robot: rules of the game

Robot questions show a grid; the robot is a triangle pointing in its facing direction. The four primitives:

Critical conventions:

• Rotations don't move; moves don't rotate. ROTATE_LEFT() then MOVE_FORWARD() = turn, then step.
• CAN_MOVE tests; it does not move. It returns false if the square that way is blocked (black/gray cell) or off the grid.
• Left and right are the ROBOT'S left and right, not yours. A robot facing down/south has its left toward the grid's east. This is the #1 robot error — always re-orient with the triangle, not the page.
• If the robot tries to MOVE_FORWARD into a wall or off the grid, the program cannot do it (treat as an error/stuck — questions are built so correct code never tries).

Tracing a robot program

[DIAGRAM: 3×3 grid. Robot in bottom-left cell (row 1, col 1), facing right/east.
No blocked cells. Goal: gray target circle in top-right cell (row 3, col 3).]

MOVE_FORWARD()
MOVE_FORWARD()
ROTATE_LEFT()
MOVE_FORWARD()
MOVE_FORWARD()

Trace with position + facing: start (1,1) E → (1,2) E → (1,3) E → rotate: (1,3) N → (2,3) N → (3,3) N. Goal reached. Notation tip: track (row, col, facing) as a little table, updating one command at a time — it's the robot's trace table.

CAN_MOVE + nesting: the wall-follower brain

IF (CAN_MOVE(forward))
{
    MOVE_FORWARD()
}
ELSE
{
    IF (CAN_MOVE(left))
    {
        ROTATE_LEFT()
        MOVE_FORWARD()
    }
    ELSE
    {
        ROTATE_RIGHT()
    }
}

In words: go straight if possible; otherwise turn left and go if possible; otherwise just turn right (and this pass makes no move). Read robot conditionals as behavior rules — "prefer forward, then left, else pivot right" — then apply them square by square. Once loops arrive (Lesson 11), this exact block becomes a maze-walker.

Worked Examples

Example 1 (easy): One input, one path

Problem: With n ← 12, what is displayed?

IF (n > 10)
{
    IF (n MOD 2 = 0)
    {
        DISPLAY ("big even")
    }
    ELSE
    {
        DISPLAY ("big odd")
    }
}
ELSE
{
    DISPLAY ("small")
}

Solution: 12 > 10 T → enter outer IF. 12 MOD 2 = 0 T → "big even". The ELSE branches never happen — for this input they may as well not exist.

Example 2 (medium): The broken chain

Problem: Shipping: orders over $100 ship free; orders over $50 ship for $5; others $10. For which order value does this code give the WRONG cost?

IF (total > 50)
{
    cost ← 5
}
ELSE
{
    IF (total > 100)
    {
        cost ← 0
    }
    ELSE
    {
        cost ← 10
    }
}

Solution: Take total = 150: 150 > 50 T → cost 5. Should be free. The > 100 test is unreachable (it sits where total ≤ 50). Any total over $100 is wrong — charged $5 instead of $0. Fix: test > 100 first, then > 50, then else.

Interpretation: Broad condition first = specific case swallowed. When the exam asks "which input reveals the error," look above the specific test for a broader one that captures it.

Example 3 (medium): Robot orientation

Problem: A robot faces south (down the page). It executes: ROTATE_LEFT(), MOVE_FORWARD(), ROTATE_RIGHT(), MOVE_FORWARD(). Facing south at (3,2) — row 3, column 2, rows numbered upward — where does it end, facing which way?

Solution: Facing south, ROTATE_LEFT turns counterclockwise from the robot's view: south → east. MOVE_FORWARD: (3,2) → (3,3), facing east. ROTATE_RIGHT: east → south. MOVE_FORWARD: (3,3) → (2,3). Ends at (2,3), facing south.

Interpretation: Left/right are the robot's. The reliable trick: physically rotate your pencil (or your head) to face the robot's direction before every turn. Ninety seconds of feeling silly beats a lost point.

Example 4 (AP-style): Behavior-rule reading

Problem: The robot runs the wall-follower block from section (b) exactly once. The square ahead is blocked; the square to the robot's left is open. What happens?

(A) The robot moves forward (B) The robot rotates left and moves one square (C) The robot rotates right and stays (D) The robot moves left without rotating

Solution: CAN_MOVE(forward) false → ELSE → CAN_MOVE(left) true → ROTATE_LEFT, MOVE_FORWARD. (B).

Interpretation: (D) is the trap for students who think the robot can strafe. It can't — it only ever moves forward; going left requires turning left first. That's why the rotate-then-move pair is idiomatic.

Common Mistakes

1. Evaluating inner conditions that were never reached. An inner IF exists only inside its branch. Cross out untaken branches while tracing.
2. Broad-before-specific chains. > 50 before > 100 makes the second unreachable. Most-specific first — and when the exam shows the broken order, the misbehaving inputs are the specific ones.
3. Robot left/right from the reader's view. It's the robot's left. Re-orient with the triangle every rotation.
4. Thinking ROTATE moves or CAN_MOVE moves. Rotations spin in place; CAN_MOVE only asks. Only MOVE_FORWARD changes position.
5. Losing track after two commands. Keep a (row, col, facing) log line per command. Mental tracking fails at exactly the length the exam uses.

Practice Problems

IF (x > 5)
{
    IF (x > 10)
    {
        DISPLAY ("huge")
    }
    ELSE
    {
        DISPLAY ("medium")
    }
}
ELSE
{
    DISPLAY ("small")
}

IF (CAN_MOVE(forward))
{
    MOVE_FORWARD()
}
ROTATE_LEFT()
MOVE_FORWARD()

IF (a > b)
{
    DISPLAY ("first")
}
ELSE
{
    IF (a = b)
    {
        DISPLAY ("second")
    }
    ELSE
    {
        DISPLAY ("third")
    }
}

Create PT Connection

Nested decisions show up in stronger PT programs the moment one condition isn't enough: if the entry is valid, then check whether it beats the record. If your procedure's selection (Lesson 9) is nested, Written Response 2(a) gets richer — you can explain not just what each condition does but why the inner one depends on the outer:

"The outer IF verifies the input is usable; only then does the inner IF compare it against the current best. Without the nesting, an invalid entry could overwrite the record."

One caution for PT design: don't nest deeper than you can explain. Two levels with clear purpose beats four levels of tangle — the rubric rewards a working algorithm you can articulate, not complexity for its own sake.