← 0478 CS HubPaper 22 · Winter 20240478 / Paper 2Question 1215 MARKS
15-mark question lab · start here
From room measurements to a full house area report.
Build the solution in a sensible order: input and validate the room count, take every room’s name, length and width, store each area rounded to two decimal places, track the largest and smallest rooms, then print the complete report with the house totals. Learn the reasoning before revealing the complete program.
1D + 2D arraysInput validationROUND to 2 dpLargest and smallestParallel indexes15 marks
Learning targets
By the end, you should be able to explain the algorithm before writing it.
Lesson overview
01 · Understand
Identify the two arrays and their shared room index, and see that this program inputs everything itself: the number of rooms and every room’s name, length and width.
02 · Construct
Build the validation loop for the room count (at least 3, no more than 20), then store each area as length multiplied by width, rounded to two decimal places with ROUND(x, 2).
03 · Complete
Track the largest and smallest rooms by area while the data is entered, then output the full table, the champion names and the total and average areas to two decimal places.
!
How Cambridge awards the marks: the mark scheme gives AO2 a maximum of 9 marks and AO3 a maximum of 6 marks. It lists requirements R1–R5, but does not assign a separate fixed mark total to each R requirement. The stage-to-mark links in this guide show alignment, not invented stage marks.
Source question
Read the whole question first
Do not begin coding after the first paragraph. The shared room index, the two-decimal rounding and the three-part output section all shape the structure of your answer.
A one-dimensional (1D) array Rooms[] contains the names of up to 20 rooms in a house. A two-dimensional (2D) array Dimensions[] is used to store the length, width and area of each room.
The position of any room’s data is the same in both arrays. For example, the data in index 5 of Dimensions[] belongs to the room in index 5 of Rooms[]
The variable Number stores the number of rooms for which data is to be input. There must be at least 3 rooms but no more than 20.
Write a program that meets the following requirements:
allows the number of rooms for which data is required to be input, stored and validated
allows the name of the room and the length and width of the room, in metres, to be entered and stored
allows the area of each room to be calculated as length multiplied by width and stored as square metres rounded to two decimal places
calculates the average size of all the rooms by area, in square metres, rounded to two decimal places
finds the largest room and smallest room by area
outputs the names of all rooms with their dimensions and area
outputs the names of the largest room and smallest room by area
outputs the total area of the house and the average size of all the rooms by area.
You must use pseudocode or program code and add comments to explain how your code works.
You do not need to declare any arrays or variables; you may assume that this has already been done.
All inputs and outputs must contain suitable messages.
Before you move on
These are the five required techniques identified by the Cambridge mark scheme.
Mark-scheme map
R1
Input the number of rooms into Number and validate it against the inclusive range 3 to 20 before any room data is taken.
R2
Input each room’s name into Rooms[] and its length and width in metres into Dimensions[,], keeping the two arrays parallel by index.
R3
Calculate each area as length multiplied by width and store it in the third column of Dimensions[,] rounded to two decimal places with ROUND(x, 2).
R4
Track the largest and smallest rooms by area while the rooms are entered, storing each champion’s area and name together.
R5
Output every room with its dimensions and area, the largest and smallest room names, and the total and average areas rounded to two decimal places.
Use the tabs along the top to work through the seven stages. The complete solution is kept in its own tab, and the interactive visualisation is the final tab.
01
Decode the requirements
Turn the question wording into a sequence of tasks.
R1 · R2 · R3 · R4 · R5
🧠 Step-by-step thinking
Spot that this program inputs its own data. Nothing is pre-stored. The room count and every room’s name, length and width are typed in at run time, so INPUT statements with suitable messages drive the whole program.
Count the two passes over the data. One FOR loop fills the arrays — name, length, width, area, total and champions. A second FOR loop afterwards prints the finished table of all rooms with their dimensions and area.
Identify the stored calculation. Each area is calculated as length multiplied by width and stored in Dimensions[Counter, 3], rounded to two decimal places — it is not just displayed.
Separate the champions from the table. The largest and smallest rooms are found while the rooms are entered. Both trackers must remember the room’s name as well as its area, because the outputs ask for names.
Translate command words. “Input, stored and validated” means a range-checked loop for Number; “rounded to two decimal places” means ROUND(x, 2); “finds” means tracking comparisons; “outputs” means display with suitable messages.
Input-driven programTwo loops: fill, then reportROUND(x, 2) storageLargest and smallest pair
❓ Guiding questions – think before revealing
Which value must be input before anything else?
Why are there two FOR loops over Rooms[]?
What does “stored as square metres rounded to two decimal places” change?
Reveal suggested reasoning
Which value must be input before anything else? Number, the room count. Every later loop runs FOR Counter ← 1 TO Number, so the count has to be known and validated (3 to 20) before the first room is requested.
Why are there two FOR loops over Rooms[]? The first loop fills the arrays and tracks the champions. The second prints the finished table once every room is stored — printing during input would show each room before the champions are known.
What does “stored as square metres rounded to two decimal places” change? The area must be written into Dimensions[Counter, 3] with ROUND(length × width, 2) — not output raw, and not truncated with INT.
Reveal Cambridge pseudocode for Stage 1
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
// 1. Input + validate Number (at least 3, no more than 20)
// 2. Zero TotalArea; champions wait for room 1
// 3. FOR Counter ← 1 TO Number:
// input name into Rooms[]
// input length + width into Dimensions[,]
// store ROUND(length * width, 2) in column 3
// add to TotalArea; test largest and smallest
// 4. AverageArea ← ROUND(TotalArea / Number, 2)
// 5. Output every room: name, length, width, area
// 6. Output largest + smallest room names
// 7. Output total area of the house + average
📖 Detailed explanation
“Allows the number of rooms … to be input, stored and validated” puts a validated REPEAT loop before everything else — Number must land between 3 and 20 before the first room is requested.
“The position of any room’s data is the same in both arrays” means one Counter indexes everything: Rooms[Counter] names the room whose figures sit in row Counter of Dimensions.
“Rounded to two decimal places” appears twice — for each stored area and for the average. Both need ROUND(x, 2), the two-argument rounding Cambridge pseudocode provides.
“Finds the largest room and smallest room by area” is a pair of trackers updated inside the input loop, because the answers must be complete before the output section runs.
⚠️ Common mistakes
Starting the room-input loop before validating Number, so an out-of-range count could overrun the arrays.
Calculating each area only when printing, and never storing it in Dimensions[Counter, 3] as the bullet demands.
Producing the table, champions and totals inside the input loop, printing four half-finished reports.
Forgetting that every input and output needs a suitable message — silent INPUT statements lose the final line’s marks.
💡 Exam hack / tip
Underline “at least 3 rooms but no more than 20”, “stored as square metres rounded to two decimal places” and “finds the largest room and smallest room”. Those phrases reveal the whole shape: a validated count, ROUND(x, 2) storage, and a champion pair built during input.
Reveal the Cambridge mark-scheme and rubric connection
This planning stage supports AO2 by identifying the full range of techniques required. It supports AO3 by establishing a logical sequence. These are alignment notes, not separately allocated marks.
02
Plan the data and identifiers
Choose variables that store exactly what the algorithm needs.
Required data structures
🧠 Step-by-step thinking
Use the given names.Rooms[], Dimensions[] and Number are supplied by the question — your program must use them exactly, including the count variable called Number.
Give Dimensions[,] a column order. Column 1 = length, column 2 = width, column 3 = area. Fix that order now, comment it, and keep every access consistent with it.
Add one loop counter.Counter walks the rooms — the same index for Rooms[] and all three columns of Dimensions[,].
Add the accumulator and trackers.TotalArea sums the stored areas; LargestArea and SmallestArea remember the extreme areas; LargestRoom and SmallestRoom remember the matching names.
Add the average.AverageArea is calculated once, after the input loop, from the completed total.
Given: Rooms[] and Dimensions[,]Given count: NumberTrackers: largest and smallest pair
❓ Guiding questions – think before revealing
Why do the two arrays share one index?
Why store the champions as areas plus names?
Do any new arrays need declaring?
Reveal suggested reasoning
Why do the two arrays share one index? The question states that the data in index 5 of Dimensions[] belongs to the room in index 5 of Rooms[]. Storing every room’s figures at the same Counter keeps that pairing intact.
Why store the champions as areas plus names? The final outputs ask for the largest and smallest room names, but the comparisons run on areas. Each tracker needs both — or one index stored and the name looked up later.
Do any new arrays need declaring? No. The question says you may assume all arrays and variables are already declared, and every result fits in the given structures plus simple variables.
Reveal Cambridge pseudocode for Stage 2
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
// Given by the question (already declared):
// Rooms[] - room names, up to 20
// Dimensions[20, 3] - 1 = length, 2 = width, 3 = area
// Number - rooms to be entered (3 to 20)
// Working variables this program needs:
// Counter - room loop index, shared by both arrays
// TotalArea - sum of all stored areas
// LargestArea - biggest stored area so far
// SmallestArea - smallest stored area so far
// LargestRoom - name of the largest room
// SmallestRoom - name of the smallest room
// AverageArea - total ÷ Number, rounded to 2 dp
📖 Detailed explanation
Meaningful identifiers earn AO3 credit.LargestRoom and SmallestRoom make it obvious which name belongs to which extreme — no examiner has to guess.
Column 3 is written by the program. Columns 1 and 2 are input; column 3 holds the stored, rounded area. Commenting that split prevents the classic mistake of printing a raw product.
Keep the question’s capitalisation.Number is a strange name for a count, but it is the name the question gives — renaming it risks losing credit for using the supplied identifiers.
⚠️ Common mistakes
Renaming Number to NoOfRooms — the question’s variable names must be used as given.
Storing the area in a separate new 1D array instead of Dimensions[Counter, 3], which the question describes.
Swapping the column order halfway through, so width lands in the length column and later prompts contradict the data.
Declaring extra arrays for results that simple variables already hold.
💡 Exam hack / tip
Write the column map in the margin once: 1 = length, 2 = width, 3 = area. Every access in your program should be checkable against that three-word map.
Reveal the Cambridge mark-scheme and rubric connection
AO2 · appropriate data structuresR2 · R3 · given names reusedAO3 · meaningful identifiers
The data plan supports AO2 because the chosen variables store exactly the required data, and AO3 because every identifier is meaningful. These are alignment notes, not separately allocated marks.
03
Validate the room count and prepare the trackers
Range-check Number, then give the totals and champions a known start.
R1 · R4
🧠 Step-by-step thinking
Loop until the count is legal. Number must be at least 3 and no more than 20, so wrap the INPUT in a REPEAT … UNTIL Number >= 3 AND Number <= 20 with a rejection message.
Zero the accumulator once.TotalArea ← 0 before the input loop — it accumulates across all rooms and must never reset.
Seed the champions from the first room. Rather than inventing sentinel values, the first room takes both titles: IF Counter = 1 stores its area and name in all four champion variables.
Keep the seeding inside the loop. The first room’s area does not exist until it has been entered and rounded, so the seed cannot happen before the loop starts.
Check the reset positions. Only TotalArea is set before the loop; the champions are written by the first pass and defended by comparisons after that.
Range check: 3 to 20Once: TotalArea ← 0Seed: first room takes both titles
❓ Guiding questions – think before revealing
Why REPEAT … UNTIL rather than a single IF?
Why seed the champions from room 1 instead of 0 and 999999?
Which values must survive from room to room?
Reveal suggested reasoning
Why REPEAT … UNTIL rather than a single IF? “Validated” means the user must be kept re-entering until the value is legal. A single IF rejects once and then carries on with a bad count.
Why seed the champions from room 1 instead of 0 and 999999? The first room’s stored area is a real value, so both trackers start correct for any data — no guessing how big or small an area could be. It also guarantees both champion names are set even with the minimum three rooms.
Which values must survive from room to room? TotalArea, the two champion areas and the two champion names. Nothing except the per-room inputs may be reset inside the loop.
Reveal Cambridge pseudocode for Stage 3
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
// Input and validate the number of rooms (R1)
REPEAT
OUTPUT "How many rooms need entering (3 to 20)? "
INPUT Number
IF Number < 3 OR Number > 20
THEN
OUTPUT "Invalid - the number of rooms must be between 3 and 20"
ENDIF
UNTIL Number >= 3 AND Number <= 20
// Prepare the accumulator; champions wait for room 1
TotalArea ← 0
// inside the loop: IF Counter = 1 seeds
// LargestArea, SmallestArea, LargestRoom, SmallestRoom
📖 Detailed explanation
The range is inclusive at both ends. Three rooms are allowed and twenty are allowed, so the accepting condition is Number >= 3 AND Number <= 20 — both comparisons include the boundary.
The rejection message doubles as the re-prompt. Printing why the value failed — with a suitable message — satisfies the question’s last line and tells the user what to type next.
Seeding at Counter = 1 is a standard Cambridge pattern. It removes sentinel guesses and keeps the later comparison tests strictly greater and strictly less for every remaining room.
⚠️ Common mistakes
Writing UNTIL Number > 3 AND Number < 20, which wrongly rejects exactly 3 and exactly 20 rooms.
Initialising the smallest-area tracker to 0, so the strictly-less test can never succeed.
Seeding the champions before the loop from an invented value like 100 m².
Resetting TotalArea inside the input loop, so the final total holds only the last room.
💡 Exam hack / tip
Say the acceptance rule aloud from the question’s own words — “at least 3 … no more than 20” — then copy it straight into the UNTIL line as >= 3 AND <= 20.
Reveal the Cambridge mark-scheme and rubric connection
AO2 · validation loopR1 · range 3 to 20 inclusiveAO3 · reliable starting state
Validation and initialisation supply AO2 evidence for checked input, and AO3 evidence for a reliable starting state. These are alignment notes, not separately allocated marks.
04
Input every room’s name, length and width
One Counter fills Rooms[] and the first two columns of Dimensions[,].
R2
🧠 Step-by-step thinking
Loop from 1 to Number. The FOR loop repeats once per room, using Counter as the shared index for both arrays.
Store the name first.INPUT Rooms[Counter] puts the name into the 1D array before anything else, so the later prompts can quote it.
Store length and width in metres.INPUT Dimensions[Counter, 1] and INPUT Dimensions[Counter, 2] — row Counter, columns 1 and 2, exactly as the bullet requires.
Prompt before every input. Each OUTPUT names the room and the value wanted — the question’s final line makes suitable messages compulsory.
No processing yet. This loop stage only enters and stores; the area calculation, total and champion tests are the next stages’ work inside the same loop.
FOR Counter ← 1 TO NumberTwo arrays, one indexPrompted inputs
❓ Guiding questions – think before revealing
Why is the name stored before length and width are requested?
Where exactly do length and width go?
Why not read the measurements into simple variables first?
Reveal suggested reasoning
Why is the name stored before length and width are requested? The later prompts can then include Rooms[Counter], so the user always knows which room they are measuring — and the shared index is exercised from the first statement.
Where exactly do length and width go? Row Counter of Dimensions[,]: column 1 for length, column 2 for width, both in metres as the bullet states.
Why not read the measurements into simple variables first? The bullet says “entered and stored” — storing straight into the arrays at Counter satisfies it with no copying step to get wrong.
Reveal Cambridge pseudocode for Stage 4
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
FOR Counter ← 1 TO Number
OUTPUT "Enter the name of room ", Counter, ": "
INPUT Rooms[Counter]
OUTPUT "Enter the length of ", Rooms[Counter], " in metres: "
INPUT Dimensions[Counter, 1]
OUTPUT "Enter the width of ", Rooms[Counter], " in metres: "
INPUT Dimensions[Counter, 2]
...
NEXT Counter
📖 Detailed explanation
One index runs the whole row.Rooms[Counter], Dimensions[Counter, 1] and Dimensions[Counter, 2] all belong to the same room — the parallel-array rule from the question’s introduction.
The prompts quote the stored name. Because Rooms[Counter] was filled first, the length prompt can say “Enter the length of Lounge in metres” — a suitable, specific message.
Metres are the question’s unit. No conversion is needed; the area in square metres comes from multiplying the two stored values exactly as they were entered.
⚠️ Common mistakes
Using a different counter for each array, breaking the parallel-index rule.
Forgetting the prompts, so inputs happen silently.
Storing the name in Dimensions[Counter, 1] by mistake and shuffling every column after it.
Looping FOR Counter ← 0 TO Number - 1 — Cambridge pseudocode indexes from 1.
💡 Exam hack / tip
Narrate each statement with the row number: “room 3’s name into Rooms[3], room 3’s length into Dimensions[3, 1], room 3’s width into Dimensions[3, 2]”. If the row number differs anywhere, the parallel arrays have slipped.
Reveal the Cambridge mark-scheme and rubric connection
AO2 · array input with iterationR2 · names and dimensions storedAO3 · suitable messages
The input loop is the AO2 evidence for iterative array filling, and the prompted messages are AO3 communication evidence. These are alignment notes, not separately allocated marks.
05
Store each area rounded to two decimal places
Multiply, round, store — then add to the house total.
R3
🧠 Step-by-step thinking
Calculate from the stored cells.Dimensions[Counter, 3] ← ROUND(Dimensions[Counter, 1] * Dimensions[Counter, 2], 2) uses the values just entered, from the same row.
ROUND takes two arguments. Cambridge pseudocode’s ROUND(x, 2) rounds to two decimal places — exactly what the bullet demands, with no INT(x + 0.5) construction needed.
Store, don’t just display. The bullet says the area is “stored as square metres rounded to two decimal places”, so the rounded value must land in column 3.
Add the stored area to the total.TotalArea ← TotalArea + Dimensions[Counter, 3] — adding the rounded value keeps the total consistent with the table that will be printed.
Do the work inside the same loop. The area is calculated while the room’s measurements still sit in Counter’s row — no second pass needed.
ROUND(x, 2)Store in column 3Accumulate TotalArea
❓ Guiding questions – think before revealing
Why ROUND(x, 2) and not INT(x)?
Why add the rounded area to the total, not the raw product?
What does the sample room 2.37 m × 3.4 m show?
Reveal suggested reasoning
Why ROUND(x, 2) and not INT(x)? INT truncates to a whole number, destroying the precision the question explicitly wants kept. ROUND(x, 2) keeps two decimal places — 8.058 becomes 8.06, not 8.
Why add the rounded area to the total, not the raw product? The program prints the stored areas later, and the total must equal the sum of the printed table. Adding raw products can leave the total a fraction away from the printed areas.
What does the sample room 2.37 m × 3.4 m show? The raw product 8.058 needs genuine rounding: ROUND(8.058, 2) stores 8.06. An exact product like 5.0 × 4.2 = 21 stores as 21.00 with nothing to round.
Reveal Cambridge pseudocode for Stage 5
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
// Still inside the FOR loop, after the inputs
Dimensions[Counter, 3] ←
ROUND(Dimensions[Counter, 1] * Dimensions[Counter, 2], 2)
// Accumulate the house total from the stored area
TotalArea ← TotalArea + Dimensions[Counter, 3]
📖 Detailed explanation
The two-argument ROUND is in the specification. Cambridge pseudocode provides ROUND(x[, places]); supplying 2 makes the rounding requirement unmistakable to the examiner.
Column 3 completes the row. After this statement, the room’s name (in Rooms[]), length, width and rounded area are all stored — everything the output table needs.
Totalling inside the loop avoids a second pass. The total is finished the moment NEXT Counter runs for the last time.
⚠️ Common mistakes
Using INT(length * width), which throws away the decimals the question explicitly wants kept.
Writing ROUND(x) with no second argument, leaving the number of places ambiguous.
Outputting the area here and never storing it, failing the “stored” half of the bullet.
Adding the raw product to TotalArea, so the printed total can disagree with the printed areas.
💡 Exam hack / tip
Memorise the one-liner store then sum: the rounded area goes into Dimensions[Counter, 3] first, and TotalArea feeds on the stored value. Two statements, correct forever.
Reveal the Cambridge mark-scheme and rubric connection
AO2 · arithmetic with roundingR3 · areas stored to 2 dpAO3 · accurate expressions
The rounding and storage line is the core AO2 arithmetic evidence, and the consistent total supports AO3 accuracy. These are alignment notes, not separately allocated marks.
06
Track the largest and smallest rooms by area
Seed both titles from room 1, then defend them with two comparisons.
R4
🧠 Step-by-step thinking
Seed on the first pass.IF Counter = 1 copies the first room’s area into LargestArea and SmallestArea, and its name into LargestRoom and SmallestRoom.
Defend with strict comparisons. Later rooms take the largest title only when area > LargestArea, and the smallest only when area < SmallestArea.
Update the name with the area. Each branch writes the pair together — an area without its room name cannot answer the output bullets.
Ties keep the first room. With strict > and <, a room equal to the current extreme never replaces it — the standard, expected behaviour.
Run the tests inside the input loop. Every stored area gets exactly one attempt at each title, immediately after it is calculated.
Seed: Counter = 1Strictly greater / strictly lessName stored with area
❓ Guiding questions – think before revealing
Why does the first room take both titles?
Why strict rather than >= and <=?
Could the champions be found after the loop instead?
Reveal suggested reasoning
Why does the first room take both titles? With one area seen, it is simultaneously the largest and the smallest. Seeding both trackers from it means every later comparison runs against a real, legal value.
Why strict rather than >= and <=? An equal area carries no new information, and a swap would point the champion names at the later room. Strict tests keep the first occurrence — what the mark scheme expects.
Could the champions be found after the loop instead? Yes — a second pass over Dimensions[,] could find both extremes. But testing each area as it is stored does the job with no extra loop.
Reveal Cambridge pseudocode for Stage 6
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
// Still inside the FOR loop
IF Counter = 1
THEN
// first room seeds both champions
LargestArea ← Dimensions[Counter, 3]
SmallestArea ← Dimensions[Counter, 3]
LargestRoom ← Rooms[Counter]
SmallestRoom ← Rooms[Counter]
ELSE
IF Dimensions[Counter, 3] > LargestArea
THEN
LargestArea ← Dimensions[Counter, 3]
LargestRoom ← Rooms[Counter]
ENDIF
IF Dimensions[Counter, 3] < SmallestArea
THEN
SmallestArea ← Dimensions[Counter, 3]
SmallestRoom ← Rooms[Counter]
ENDIF
ENDIF
📖 Detailed explanation
One room can hold both titles. After room 1, LargestArea and SmallestArea are equal — perfectly correct while only one area exists.
The ELSE separates seeding from defence. Without it, room 1’s area would be compared against itself — harmless here, but the explicit branch documents the intent and survives data changes.
Four variables, two pairs.LargestArea with LargestRoom, and SmallestArea with SmallestRoom. Every update writes a complete pair.
⚠️ Common mistakes
Tracking only the largest, then improvising the smallest at the end.
Using >= for the largest test, so equal areas overwrite the first champion’s name.
Updating LargestArea but not LargestRoom, printing a stale name.
Comparing lengths or widths instead of the stored, rounded areas — the question says “by area”.
💡 Exam hack / tip
Champion pairs travel together: area in, name in — in the same branch. Count the assignments in each IF; there should always be two.
Reveal the Cambridge mark-scheme and rubric connection
AO2 · max and min trackingR4 · largest and smallest by areaAO3 · consistent paired updates
This stage supplies the selection and tracking evidence for AO2, and the paired-update discipline for AO3. These are alignment notes, not separately allocated marks.
07
Average, then the three output sections
Round the average, print the table, the champions and the house totals.
R5
🧠 Step-by-step thinking
Round the average once.AverageArea ← ROUND(TotalArea / Number, 2) after the loop — the same two-decimal rule as the stored areas.
Table first. A second FOR loop prints every room’s name, length, width and stored area — the first output bullet, and the reason column 3 had to be stored.
Then the champions by name.LargestRoom and SmallestRoom already hold the names the next two bullets ask for.
Finish with total and average. The last bullet wants both on the house scale — TotalArea and AverageArea, each with a suitable message.
Everything prints after the loop. No room is processed in the output section, so nothing can be half-finished when it appears.
ROUND(TotalArea / Number, 2)Output loop: full tableThree summary outputs
❓ Guiding questions – think before revealing
Why is the average calculated after NEXT Counter?
Why print the table from the arrays rather than echoing during input?
Which values still need rounding in the output section?
Reveal suggested reasoning
Why is the average calculated after NEXT Counter? Only then is TotalArea complete. Dividing earlier would average a part-finished total — a wrong answer no later step can repair.
Why print the table from the arrays rather than echoing during input? The bullet lists the table as a program output, and echoing during input would print each room before its champions were decided. One clean loop prints the finished rows in order.
Which values still need rounding in the output section? Only the average — the areas and the total are already stored to two decimal places, so they print exactly as calculated.
Reveal Cambridge pseudocode for Stage 7
CODE PLAN · STRUCTURE ONLYBuild this before filling in the details
NEXT Counter
// Average size of all the rooms by area, to 2 dp
AverageArea ← ROUND(TotalArea / Number, 2)
// Output every room with its dimensions and area
FOR Counter ← 1 TO Number
OUTPUT Rooms[Counter], ": length ",
Dimensions[Counter, 1], " m, width ",
Dimensions[Counter, 2], " m, area ",
Dimensions[Counter, 3], " m²"
NEXT Counter
// Largest and smallest rooms by name
OUTPUT "Largest room by area: ", LargestRoom
OUTPUT "Smallest room by area: ", SmallestRoom
// Total area of the house and average room size
OUTPUT "Total area of the house: ", TotalArea, " m²"
OUTPUT "Average size of all the rooms by area: ", AverageArea, " m²"
📖 Detailed explanation
The average uses the same ROUND idiom.TotalArea / Number gives 12.0475 in the sample; ROUND(…, 2) stores 12.05 for printing.
The output loop is read-only. It prints Rooms[Counter] and the three columns of Dimensions[Counter, …] without changing anything — a safe, repeatable pattern.
Bullet order is output order. Table, then champions, then total and average — walking the question’s last three output bullets in sequence guarantees nothing is missed.
⚠️ Common mistakes
Calculating AverageArea inside the input loop, dividing an unfinished total.
Printing room numbers instead of Rooms[Counter] in the table.
Outputting LargestArea where the question asks for the room name.
Forgetting the final total and average outputs — the question’s last bullet is the most commonly dropped.
💡 Exam hack / tip
Tick the last three bullets as you write: table, champions, total + average. Three ticks after NEXT Counter and the response is complete.
Reveal the Cambridge mark-scheme and rubric connection
The output section delivers R5 in full, and the rounded, messaged outputs are AO3 accuracy evidence. These are alignment notes, not separately allocated marks.
Cambridge assessment criteria
What does a high-level response look like?
The mark scheme assesses the answer across AO2 and AO3. Use these descriptors to check the whole program, not just one isolated code section.
9 AO2 + 6 AO3 = 15
AO2 · Apply knowledge and understandingMaximum 9 marks · programming techniques and data structures
Band
What the descriptor means
0
No creditable response.
1–3
At least one programming technique is used. Some data is stored, but not appropriately. Any use of iteration, selection, counting, totalling, input or output may be credited.
4–6
Some programming techniques are appropriate to the problem, with more than one technique applied. Some data structures are appropriate and store some of the required data.
7–9
The full range of techniques needed by the scenario is used appropriately. The chosen data structures are appropriate and store all the required data.
AO3 · Provide solutions to problemsMaximum 6 marks · comments, identifiers, logic and accuracy
Band
What the descriptor means
0
No creditable response.
1–2
Program seen without relevant comments. Some identifier names and some data-structure names are appropriate. The solution may be illogical or inaccurate in many places, but attempts at least one requirement.
3–4
Program seen with some relevant comments. The majority of identifiers and most data-structure names are meaningful. Parts may be illogical or inaccurate, but most requirements are met.
5–6
The program is fully commented. Suitable identifiers are meaningful throughout, and all data structures have meaningful names. The program is logical and accurate and meets all requirements; minor syntax errors are ignored.
How the seven stages contribute
These are links to the assessment criteria, not separate mark allocations.
R1–R5
Stage
Mark-scheme link
AO2 evidence
AO3 evidence
1 · Decode
R1–R5
Identifies the input-driven structure, the two loops and both rounding demands.
Establishes logical order and comments plan.
2 · Data
Required data structures
Rooms[], the three Dimensions[,] columns and the tracker variables.
Meaningful identifiers; given names reused.
3 · Initialise
R1, R4
Number validated 3–20; TotalArea zeroed; champions seeded from room 1.
Inclusive range check and reliable starting state.
4 · Input
R2
Names, lengths and widths entered and stored at the shared index.
Suitable prompts on every input.
5 · Areas
R3
ROUND(length × width, 2) stored in column 3 and accumulated.
Accurate ROUND expression; stored, not just displayed.
6 · Champions
R4
Largest and smallest tracked by area with names, seeded from room 1.
Strict comparisons keep the first occurrence.
7 · Summary
R5
Average rounded; table, champion names and house totals output.
Complete, messaged outputs after the loop.
Final self-check
Tick each statement only when it is present and correct in your answer.
Student checklist
0 of 10 completed
✓
Target: to reach the top AO2 and AO3 bands, the solution needs to be appropriate, logical, accurate, commented, and complete. A long answer alone does not guarantee full marks.
Consolidated Cambridge pseudocode
Complete solution
The full answer is presented in one place after the seven stages. Try to construct it yourself before opening this tab during revision.
15-mark exemplar style
Read this carefully: this follows the structure and techniques of the specimen mark scheme. Rooms[], Dimensions[] and Number are treated as already declared, exactly as the question allows, and the Dimensions columns run 1 = length, 2 = width, 3 = area. The champion variables are seeded from the first room, so no sentinel values are needed.
QUESTION 12 · FULL PSEUDOCODECambridge 0478 style · 1-based indexing
// Rooms[], Dimensions[] and Number are assumed to be declared
// Dimensions columns: 1 = length, 2 = width, 3 = area
// R1: input and validate the number of rooms (3 to 20)
REPEAT
OUTPUT "How many rooms need entering (3 to 20)? "
INPUT Number
IF Number < 3 OR Number > 20
THEN
OUTPUT "Invalid - the number of rooms must be between 3 and 20"
ENDIF
UNTIL Number >= 3 AND Number <= 20
// Prepare the accumulator for the whole house
TotalArea ← 0
// Take and process every room in turn
FOR Counter ← 1 TO Number
// R2: input and store the room's name, length and width
OUTPUT "Enter the name of room ", Counter, ": "
INPUT Rooms[Counter]
OUTPUT "Enter the length of ", Rooms[Counter], " in metres: "
INPUT Dimensions[Counter, 1]
OUTPUT "Enter the width of ", Rooms[Counter], " in metres: "
INPUT Dimensions[Counter, 2]
// R3: calculate the area, rounded to 2 dp, and store it
Dimensions[Counter, 3] ← ROUND(Dimensions[Counter, 1] * Dimensions[Counter, 2], 2)
// accumulate the house total from the stored area
TotalArea ← TotalArea + Dimensions[Counter, 3]
// R4: track the largest and smallest rooms by area
IF Counter = 1
THEN
// the first room seeds both champions
LargestArea ← Dimensions[Counter, 3]
SmallestArea ← Dimensions[Counter, 3]
LargestRoom ← Rooms[Counter]
SmallestRoom ← Rooms[Counter]
ELSE
IF Dimensions[Counter, 3] > LargestArea
THEN
LargestArea ← Dimensions[Counter, 3]
LargestRoom ← Rooms[Counter]
ENDIF
IF Dimensions[Counter, 3] < SmallestArea
THEN
SmallestArea ← Dimensions[Counter, 3]
SmallestRoom ← Rooms[Counter]
ENDIF
ENDIF
NEXT Counter
// average size of all the rooms by area, to 2 dp
AverageArea ← ROUND(TotalArea / Number, 2)
// R5: output every room with its dimensions and area
FOR Counter ← 1 TO Number
OUTPUT Rooms[Counter], ": length ", Dimensions[Counter, 1], " m, width ",
Dimensions[Counter, 2], " m, area ", Dimensions[Counter, 3], " m²"
NEXT Counter
// output the largest and smallest rooms by name
OUTPUT "Largest room by area: ", LargestRoom
OUTPUT "Smallest room by area: ", SmallestRoom
// output the total area of the house and the average
OUTPUT "Total area of the house: ", TotalArea, " m²"
OUTPUT "Average size of all the rooms by area: ", AverageArea, " m²"
Why this is a complete response
It covers the mark-scheme requirements: Number input, stored and validated against the inclusive 3-to-20 range (R1), each room’s name, length and width entered and stored at the shared index (R2), every area calculated as length × width, rounded to two decimal places and stored in Dimensions[Counter, 3] (R3), the largest and smallest rooms tracked by area with their names (R4), and the complete output section — all rooms with dimensions and area, the champion names, and the total and average areas to two decimal places (R5).
What to check before submitting
Check that the REPEAT loop re-prompts until Number is inside the inclusive 3-to-20 range, that every area is stored with ROUND(x, 2) before it is totalled, that the champion pairs update together inside the input loop, and that the output loop prints names, dimensions and areas from the arrays with suitable messages.
!
Remember: the AO2 and AO3 marks are awarded by judging the whole response. The individual R1–R5 labels are the technique requirements, not a fixed per-item mark split.
Interactive execution trace
Visualisation: watch the house program run.
Step through a sample house. Watch the room count get validated, each room’s measurements arrive, the areas land in column 3 rounded to two decimal places, the champion pair change hands, and the final report print every room.
Last tab · Trace player
Sample input → expected results
Four sample rooms are entered (Number = 4, accepted on re-entry after 25 is rejected; the real question allows 3 to 20). The sample deliberately tests a rejected count, an exact product (5.0 × 4.2 = 21.00), a two-decimal product (3.4 × 4.7 = 15.98), a product needing genuine rounding (2.37 × 3.4 = 8.058, stored as 8.06), both champion titles changing hands after room 1 seeds them, and an average that rounds up (48.19 ÷ 4 = 12.0475, stored as 12.05). These are illustrative values, not data supplied by the examination question.
Input arrays Rooms[] and Dimensions[,]
Room
Length (m)
Width (m)
The row number is the index shared by Rooms[] and Dimensions[,]. The area column is not shown because the program calculates and stores it in Dimensions[Counter, 3].
Reveal expected room results and house summary
Expected room results After all calculations
Room
Length (m)
Width (m)
Area (m²)
Role
Execution trace
Step 1 of 1
Initialisation
Initialisation
The program begins.
Program output so far
(No output yet)
Live variable values
House counters
Ready
Tip: use Next step slowly and watch Counter, TotalArea and the two champion areas. The trackers start empty and are seeded by room 1 — after that, only a strictly greater or strictly smaller area can take a title.
Trace colours: blue row = current room; amber cell = current measurement being entered; green cells = measurements already stored.
Rounding examples: the main bedroom’s 2.37 × 3.4 = 8.058 needs genuine rounding, so ROUND(8.058, 2) stores 8.06, while the lounge’s exact 5.0 × 4.2 = 21 stores as 21.00 with nothing to round. The average needs rounding too: 48.19 ÷ 4 = 12.0475 and ROUND(12.0475, 2) gives 12.05.