Develop and test an algorithm from a bounded problem
Draft audience: Grade 10 intended, subject to teacher review of prerequisites and exact current subject, strand and term placement. This is original learning support, not an official curriculum allocation or marking scheme.
Developing an algorithm means deciding what valid input means, what must happen on every branch and what evidence would expose a mistake. This activity extends the complete ribbon variable-and-trace lesson, Q409. Its allocation calculation, constants and accepted-input behaviour are retained. The added job is designing and testing an input-validation boundary that Q409 deliberately left outside its calculation.
The case is fictional and paper-only. It allocates no real stock, collects no personal data and uses no accounts. Every independent run starts with 10.00 m of ribbon. Each complete length needs 1.25 m. Accept an entire valid request if it fits, including exact equality; otherwise leave the ribbon unchanged. Zero remains a valid count.
Turn the new need into explicit rules
The display team now requires a batch code consisting of exactly three characters from 0 to 9, stored as text so “007” stays “007”. The requested count must be a finite numeric whole number at least zero. Text “3” is not silently converted to numeric 3. TRUE and FALSE are not counts. The validation version reports the entered code and count, status, required amount and remaining stock.
If the code is invalid, report INVALID CODE first, even if the count is also invalid. If the code passes but the count fails, report INVALID COUNT. For either invalid case, required amount is “not calculated” and remaining stock is 10.00 m. That missing calculation is not zero demand. A valid request that exceeds stock is different: calculate and report its required amount, then report INSUFFICIENT.
| Need | Design choice | Example check |
|---|---|---|
| Preserve code meaning | Keep code as text; validate three ASCII digits without numeric conversion. | “007”, 3 retains “007”. Numeric 7 is an invalid code. |
| Reject invalid input safely | Code test precedes count test; no demand arithmetic on either invalid branch. | “7”, −1 gives INVALID CODE; unchanged 10.00 m. |
| Keep the original allocation rule | Use requiredM ≤ 10.00 and subtract only after acceptance. | “008”, 8 is READY; remaining 0.00 m. |
| Make rejection inspectable | Always output input, status, required amount or not calculated, and remaining stock. | “009”, 9 reports 11.25 m required and 10.00 m remaining. |
Complete pseudocode and decision path
IS_CODE is true only for text of length three whose characters are all 0–9. IS_COUNT is true only for a finite numeric, non-Boolean whole number at least zero. These predicates perform checks without changing the input. Assignment uses ←; comparison uses ≤. The text alternatives below define every branch without relying on a particular programming language.
INPUT code, count
requiredM ← NOT_CALCULATED
remainingM ← 10.00
status ← "UNCHECKED"
IF NOT IS_CODE(code) THEN
status ← "INVALID CODE"
ELSE IF NOT IS_COUNT(count) THEN
status ← "INVALID COUNT"
ELSE
requiredM ← count × 1.25
IF requiredM ≤ 10.00 THEN
remainingM ← 10.00 − requiredM
status ← "READY"
ELSE
status ← "INSUFFICIENT"
ENDIF
ENDIF
OUTPUT code, count, status, requiredM, remainingM
END
Decision diagram in words: input → initialise output fields → code valid? No: INVALID CODE → output. Yes: count valid? No: INVALID COUNT → output. Yes: compute demand → demand at most stock? Yes: subtract and mark READY → output. No: preserve stock and mark INSUFFICIENT → output. Every route ends; there is no loop or repeated request in this specification.
Trace the full state on a valid boundary
Use code “008”, count 8. Both inputs remain unchanged throughout; the table includes every executed assignment and decision. A dash means no assignment yet, not a number.
| After instruction or test | requiredM | remainingM | status | Decision or output |
|---|---|---|---|---|
| Input | — | — | — | No output |
| requiredM initialisation | not calculated | — | — | No output |
| remainingM initialisation | not calculated | 10.00 | — | No output |
| status initialisation | not calculated | 10.00 | UNCHECKED | No output |
| NOT IS_CODE | not calculated | 10.00 | UNCHECKED | False; code passes |
| NOT IS_COUNT | not calculated | 10.00 | UNCHECKED | False; count passes |
| Compute requiredM | 10.00 | 10.00 | UNCHECKED | 8 × 1.25 |
| requiredM ≤ 10.00 | 10.00 | 10.00 | UNCHECKED | True |
| Assign remainingM | 10.00 | 0.00 | UNCHECKED | 10.00 − 10.00 |
| Assign status | 10.00 | 0.00 | READY | No output |
| Output; end | 10.00 | 0.00 | READY | “008”, 8, READY, 10.00, 0.00 |
Trace rejection before arithmetic
| After instruction or test | requiredM | remainingM | status | Decision or output |
|---|---|---|---|---|
| Input | — | — | — | No output |
| requiredM initialisation | not calculated | — | — | No output |
| remainingM initialisation | not calculated | 10.00 | — | No output |
| status initialisation | not calculated | 10.00 | UNCHECKED | No output |
| NOT IS_CODE | not calculated | 10.00 | UNCHECKED | False |
| NOT IS_COUNT | not calculated | 10.00 | UNCHECKED | True; 2.5 is not whole |
| Assign status | not calculated | 10.00 | INVALID COUNT | No multiplication or subtraction |
| Output; end | not calculated | 10.00 | INVALID COUNT | “014”, 2.5, INVALID COUNT, not calculated, 10.00 |
The multiplication branch never runs in Trace B. Rounding 2.5 to 3 would change the request without permission. For a valid oversized request “009”, 9, the validation decisions both pass, demand becomes 11.25 m, the capacity decision is false, status becomes INSUFFICIENT and remainingM stays 10.00. The complete corresponding allocation trace is retained in Q409.
Choose representative tests before inspecting outputs
| Code input | Count input | Expected status | Required (m) | Remaining (m) |
|---|---|---|---|---|
| “000” | 0 | READY | 0.00 | 10.00 |
| “007” | 3 | READY | 3.75 | 6.25 |
| “008” | 8 | READY | 10.00 | 0.00 |
| “009” | 9 | INSUFFICIENT | 11.25 | 10.00 |
| “014” | −1 | INVALID COUNT | not calculated | 10.00 |
| “014” | 2.5 | INVALID COUNT | not calculated | 10.00 |
| “014” | text “3” | INVALID COUNT | not calculated | 10.00 |
| “7” | −1 | INVALID CODE | not calculated | 10.00 |
| numeric 7 | 3 | INVALID CODE | not calculated | 10.00 |
| “0A7” | 3 | INVALID CODE | not calculated | 10.00 |
The retained ordinary and boundary outputs agree with Q409. Newly rejected inputs test the added requirement; they do not alter the original valid-input calculation. A correct refusal message is insufficient if remaining stock changes, so check both status and state. These paper checks establish behaviour only for the declared model, not production security or suitability for simultaneous real users.
Independent design repair
- A proposal replaces ≤ with <. Name the smallest existing test that exposes the mistake and its wrong result.
- For input “021”, 6, write the output in the specified order.
- For input “21”, 2.5, identify the first failed rule and explain why demand stays uncalculated.
- A new requirement allows numeric text counts. Which records must be revised before accepting it?
Explained answers
The “008”, 8 equality test would wrongly report INSUFFICIENT while retaining 10.00 m (2 points). The new valid output is “021”, 6, READY, 7.50, 2.50 (2 points). “21” fails the three-character code test first; the count test and arithmetic are skipped, so demand remains not calculated and stock stays 10.00 (2 points). The input specification, conversion/error rules, design and expected tests must change together; decide how spaces, signs and decimals are interpreted rather than silently guessing (2 points). Total: 8 points.
Q090 remains the separate selection-and-loop tracing lesson; Q336 remains the in-place array-order lesson. Neither is relabelled or replaced here. This validation extension uses explicit local notation, not a claim of official examination notation.
WhatsApp Us Now