Set B — Decisions (Scenarios 6–10)

Thinking questions — answered.

1. “Is the order at least 2500?” → orderValue >= 2500. The requirement’s words or more are the spec: > alone would wrongly charge a 2500 order. This is lesson §19’s boundary mistake in miniature — the fix costs nothing now.
2. At 2500: delivery free, total 2500. Just below (2499): delivery 150, total 2649 — a 2499-rupee order costs more than a 2500 order! That perversity is the shop’s choice, not your bug — but it shows why the boundary deserves its own test: the two sides of it are very different worlds.
3. See the test table below — boundary, one below, ordinary cases.

Suggested approach. Straight-line IPO plus one decision. Compute the total after deciding delivery, so only one addition formula exists.

Pseudocode.

READ orderValue
IF orderValue >= 2500 THEN
    delivery ← 0
    deliveryText ← "FREE"
ELSE
    delivery ← 150
    deliveryText ← delivery + " Rs"
ENDIF
total ← orderValue + delivery
PRINT orderValue, deliveryText, total

Solution explanation. The decision sets both the numeric delivery and the display text, keeping the two consistent — a tiny design point with a big lesson: derive related outputs together, so they can never disagree. The total is computed once, after the branch, because it’s the same formula either way (orderValue + delivery — delivery just carries 0 or 150). One formula, no duplication, no possibility of the two branches drifting apart.

C++ solution.

// s06_delivery.cpp — Set B · Scenario 6
// Compile: g++ -std=c++17 -Wall -Wextra s06_delivery.cpp -o s06

#include <iostream>

int main() {
    int orderValue = 0;
    std::cout << "Order value (Rs): ";
    std::cin  >> orderValue;

    int delivery = 0;
    if (orderValue >= 2500) {
        delivery = 0;
    } else {
        delivery = 150;
    }

    int total = orderValue + delivery;

    std::cout << "Order: " << orderValue << " Rs\n";
    std::cout << "Delivery: ";
    if (delivery == 0) {
        std::cout << "FREE\n";
    } else {
        std::cout << delivery << " Rs\n";
    }
    std::cout << "Grand total: " << total << " Rs\n";
    return 0;
}

Test cases.

Edge cases. 2500 and 2499 (the boundary pair — both must be tested, by name, every time), 1 (minimum legal), 100000 (maximum — free delivery, no overflow drama at this size). A future refinement (Set D) asks: what if delivery were 150 or 5% of the order, whichever is smaller? Park it — but notice how “think about the boundary” scales up.

Thinking questions — answered.

1. Check from the top down: >= 70 first (distinction), `else if

   = 50 (pass), else (fail). Top-down ordering works because each branch only receives what the previous rejected — by the time you ask "≥ 50?", you already know it's < 70. Bottom-up with <=` works too, but mixing directions is how bands get skipped or doubled — pick one direction per chain.

2. 49 → fail; 50 → pass; 69 → pass; 70 → distinction. With >= at each band edge, all four land exactly as the requirement says. (If your draft used > 70 for distinction, 70 itself falls through to “pass” — the classic off-by-one at the boundary.)
3. 100 → distinction ✓; 0 → fail ✓. Both inside the requirement; no special handling needed — the chain’s final else is the safety net.

Suggested approach. An else-if ladder checked top-down — the standard shape for multi-band classification (grades, tariffs, tax brackets all use it later in the course).

Pseudocode.

READ percent
IF percent >= 70 THEN
    verdict ← "PASS WITH DISTINCTION"
ELSE IF percent >= 50 THEN
    verdict ← "PASS"
ELSE
    verdict ← "FAIL"
ENDIF
PRINT "Result: ", verdict

Solution explanation. Compute the verdict first, print once at the end — rather than printing inside each branch. One print statement means the format can never diverge between branches; the branches only choose the content. This “decide, then act once” shape scales beautifully: with ten bands you’d still have exactly one print.

C++ solution.

// s07_exam.cpp — Set B · Scenario 7
// Compile: g++ -std=c++17 -Wall -Wextra s07_exam.cpp -o s07

#include <iostream>

int main() {
    int percent = 0;
    std::cout << "Percentage: ";
    std::cin  >> percent;

    if (percent >= 70) {
        std::cout << "Result: PASS WITH DISTINCTION\n";
    } else if (percent >= 50) {
        std::cout << "Result: PASS\n";
    } else {
        std::cout << "Result: FAIL\n";
    }
    return 0;
}

Test cases.

Edge cases. The two boundary pairs (49/50, 69/70) — if you test nothing else, test these; 0 and 100 (the legal extremes). Out of range (−5, 105): by our assumptions, undefined — but notice that this program happily prints FAIL for −5 and DISTINCTION for 105. Defining what should happen there is exactly what Set D, Scenario 19 adds as validation.

Thinking questions — answered.

1. CHILD 1–11 · TEEN 12–17 · ADULT 18–59 · SENIOR 60–120. Writing the ranges (not the sentences) is the step that prevents overlap/gap bugs — sentences hide edges, ranges expose them.
2. The pairs: 11/12 (CHILD→TEEN), 17/18 (TEEN→ADULT), 59/60 (ADULT→SENIOR). Three edges, six tests. Plus 1 and 120 for the legal extremes.
3. Top-down ladder (like Scenario 7): age < 12 → CHILD; else age < 18 → TEEN; else age < 60 → ADULT; else SENIOR. Each branch inherits a lower bound from the previous rejection, so only the upper bound is needed per branch — no gaps or overlaps are possible by construction. (The explicit-range shape age >= 12 && age <= 17 also works and is more “self-documenting” at the cost of more conditions — Set B’s Scenario 9 uses exactly that style when branches can’t be ordered so neatly.)

Suggested approach. Else-if ladder, top-down, one condition per branch exploiting inheritance; compute category+price, print once.

Pseudocode.

READ age
IF age < 12 THEN
    category ← "CHILD";   price ← 300
ELSE IF age < 18 THEN
    category ← "TEEN";    price ← 450
ELSE IF age < 60 THEN
    category ← "ADULT";   price ← 600
ELSE
    category ← "SENIOR";  price ← 400
ENDIF
PRINT "Category: ", category
PRINT "Price: ", price, " Rs"

Solution explanation. Same skeleton as Scenario 7 — proof the classification pattern transfers unchanged from 3 bands to 4, uniform or not. The one new thinking move is deriving the ladder conditions from a range table (step 1), so the code inherits the table’s guarantee: every age lands in exactly one band. Trace-check the three boundary pairs by hand (11→300, 12→450, 17→450, 18→600, 59→600, 60→400) before trusting it.

C++ solution.

// s08_cinema.cpp — Set B · Scenario 8
// Compile: g++ -std=c++17 -Wall -Wextra s08_cinema.cpp -o s08

#include <iostream>

int main() {
    int age = 0;
    std::cout << "Age: ";
    std::cin  >> age;

    if (age < 12) {
        std::cout << "Category: CHILD\n";
        std::cout << "Price: 300 Rs\n";
    } else if (age < 18) {
        std::cout << "Category: TEEN\n";
        std::cout << "Price: 450 Rs\n";
    } else if (age < 60) {
        std::cout << "Category: ADULT\n";
        std::cout << "Price: 600 Rs\n";
    } else {
        std::cout << "Category: SENIOR\n";
        std::cout << "Price: 400 Rs\n";
    }
    return 0;
}

Test cases.

Edge cases. The three boundary pairs above; 1 and 120 (legal extremes); and the assumption edge: age 0 is excluded by the constraints (a 0-year-old isn’t a ticket-buyer) — document, don’t defend.

Thinking questions — answered.

1. ON: tempOk && !raining. OFF is its negation: !tempOk || raining — or! Negations flip and↔or (De Morgan’s laws; Unit 04 names them). Distinct OFF reasons: three user-visible (temp-not-ok, raining, both) but only two explanation categories we can honestly report — temperature and rain.
2. The 2×2: (y, n) → ON · (y, y) → OFF/RAIN · (n, n) → OFF/TEMP · (n, y) → OFF/TEMP+RAIN — the honest message can mention both conditions. All four rows must be tests.
3. The naive design promised “TOO HOT/TOO COLD” — impossible from the given inputs. Catching that on paper is free; catching it after coding means rework. This scenario is the module’s small lesson in reading requirements before designing outputs.

Suggested approach. One combined and condition for ON; if OFF, report temperature and/or rain honestly, using two independent checks.

Pseudocode.

READ tempAnswer, rainAnswer
tempOk  ← (tempAnswer = "y")
raining ← (rainAnswer = "y")

IF tempOk AND NOT raining THEN
    PRINT "MATCH ON"
ELSE
    IF NOT tempOk THEN PRINT "TEMPERATURE — outside 15–35"
    IF raining THEN PRINT "RAIN"
ENDIF

Solution explanation. Two design points worth stealing. First, the condition is written from the requirement’s sentence (“between 15 and 35 and not raining”) almost word for word — code that mirrors the requirement is checkable against it. Second, the OFF branch uses two separate ifs, not one else-if chain, because the reasons are independent: both can be true at once. else-if would silently hide one. Choosing between “chain” and “independent ifs” is the design decision here — decided from the meaning of the inputs, not from typing convenience.

C++ solution.

// s09_match.cpp — Set B · Scenario 9
// Compile: g++ -std=c++17 -Wall -Wextra s09_match.cpp -o s09

#include <iostream>

int main() {
    char tempAnswer = ' ';
    char rainAnswer = ' ';

    std::cout << "Temp OK (y/n): ";
    std::cin  >> tempAnswer;
    std::cout << "Raining (y/n): ";
    std::cin  >> rainAnswer;

    bool tempOk  = (tempAnswer == 'y');
    bool raining = (rainAnswer == 'y');

    if (tempOk && !raining) {
        std::cout << "MATCH ON\n";
    } else {
        if (!tempOk) {
            std::cout << "TEMPERATURE — outside 15-35\n";
        }
        if (raining) {
            std::cout << "RAIN\n";
        }
    }
    return 0;
}

Test cases. (the 2×2 — all four, plus nothing else exists)

Edge cases. The 2×2 is the edge set for this input design — four combinations, all tested. (If the input had been the temperature number and a rain flag, the edges would instead be 14/15 and 35/36 — the boundary discipline from Scenarios 6–8 transfers unchanged.)

Thinking questions — answered.

1. “Keep a champion: look at a, then b — whichever is smaller becomes the champion — then c.” The running minimum pattern (an accumulator of comparisons). Two comparisons, not three-choose-two chaos.
2. a <= b && a <= c. Note <= not <: with a tie (a = b), the requirement says any smallest is fine, but < with equal values would fall through every branch and print nothing — a gap. <= closes it.
3. The six arrangements of three distinct values, plus at least two tie shapes (two equal, all three equal). You’ll find the ladder below handles all of them — but you verify that, on paper, before opening.

Suggested approach. Either (a) the ladder: if (a <= b && a <= c) … else if (b <= a && b <= c) … else …, or (b) the champion: start with smallest = a, then two if updates. Both are taught; (b) is the shape that scales to ten values (Set C uses accumulators heavily), (a) is the direct translation of the definition. Dry-run both on {9, 3, 7}.

Pseudocode (champion form).

READ a, b, c
smallest ← a
IF b < smallest THEN smallest ← b
IF c < smallest THEN smallest ← c
PRINT "Smallest: ", smallest

Solution explanation. The champion form is two independent ifs — not a chain — because each new value challenges the current champion once; else-if would wrongly skip the second challenge whenever the first fired. Dry-run {9, 3, 7}: champion 9 → 3 challenges (3 < 9: champion 3) → 7 challenges (7 < 3? no) → prints 3. ✓ And {3, 9, 3}: champion 3 → 9? no → 3 < 3? no (strict <) → prints 3. ✓ Ties work because the champion already holds a smallest value and equals are no-ops.

C++ solution.

// s10_smallest.cpp — Set B · Scenario 10
// Compile: g++ -std=c++17 -Wall -Wextra s10_smallest.cpp -o s10

#include <iostream>

int main() {
    int a = 0, b = 0, c = 0;
    std::cout << "Three counts: ";
    std::cin  >> a >> b >> c;

    int smallest = a;          // the champion
    if (b < smallest) {
        smallest = b;          // b challenges and wins
    }
    if (c < smallest) {
        smallest = c;          // c challenges the current champion
    }

    std::cout << "Smallest: " << smallest << "\n";
    return 0;
}

Test cases.

Edge cases. All-equal (4,4,4 — every branch a no-op), two-equal-with- smallest (5,5,2 — and its permutations), smallest first (champion never updates), smallest last (both updates fire), 0 as the legal minimum.