15-mark question lab · start here

From blank arrays to the class’s most and least popular option.

Build the solution in a sensible order: initialise the three arrays, validate the option and voter counts, take each option string, display the list to every voter and validate each vote, tally VoteCount[], then crown the most and least popular options. Learn the reasoning before revealing the complete program.

1D arraysValidation loopsIndex tallyingMax + min trackingSuitable messages15 marks

Learning targets

By the end, you should be able to explain the algorithm before writing it.

Lesson overview

01 · Understand

Identify the three 1D arrays, the 2–12 option range, the 2–1000 voter range, and why VoteCount[] is indexed by option number.

02 · Construct

Validate both counts with re-entry loops, store every option string, and display the option list to each voter before validating and storing their vote.

03 · Complete

Tally the votes into VoteCount[], track the most and least popular options in one scan, and output both with their vote counts.

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 two validated ranges, the index-based tally and the assumed declarations all shape the structure of your solution.

Question 9 · 15 marks

Cambridge IGCSE Computer Science · 0478/22 · Question 9

A program is required to enable voting in class surveys, for example to find the most popular smartphone.

The one-dimensional (1D) array Options[] is used to store between 2 and 12 options on which users can vote.

The one-dimensional (1D) array Votes[] is used to store the votes of between 2 and 1000 users.

The one-dimensional (1D) array VoteCount[] is used to store the number of votes for each of the options. The array index represents the option number.

Write a program for the following requirements:

Initialise all the arrays before they are used.
Input and validate the number of options and the number of voters.
Input each of the required options and store them in the array Options[]
Display the list of options for each voter and allow each voter to input their preferred option. Validate this input and store it in the array Votes[]
Once all the votes have been input, count the number of voters who chose each option and find the most and least popular options.
Output the most and least popular options as well as the number of voters who selected each of these options.

The program does not need to identify if two or more options are the equal most or least popular.

You must use pseudocode or program code, and add comments to explain how your code works.

Do not declare arrays, variables or constants for this algorithm; assume this has been done.

Initialisation must be carried out as appropriate.

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

Initialise Options[], Votes[] and VoteCount[] before any of them is used.

Input and validate the number of options (2–12) and the number of voters (2–1000), re-entering any invalid value.

Input each option into Options[], then display the list to every voter, validate the preferred option number and store it in Votes[].

Once all the votes are in, count the voters who chose each option into VoteCount[] and find the most and least popular options.

Output the most and least popular options with the number of voters who selected each, using suitable messages throughout.

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.

Decode the requirements

Turn the question wording into a sequence of tasks.

R1 · R2 · R3 · R4 · R5

🧠 Step-by-step thinking

Find the three arrays. Options[] stores the option texts, Votes[] stores one vote per user, and VoteCount[] stores one tally per option — its index is the option number itself.
Find the two validated counts. The number of options must sit between 2 and 12 and the number of voters between 2 and 1000. Both need a loop that keeps asking until the value is in range.
Spot the two passes over the data. First every vote is collected voter by voter. Then, once all the votes are in, Votes[] is walked again to tally VoteCount[] and find the extremes.
Translate command words. “Initialise” means give every array a known starting value; “validate” means loop until the input is in range; “count” means tally into VoteCount[]; “most and least popular” means tracking a maximum and a minimum.
Build the order. initialise arrays → input + validate option count → input + validate voter count → input options → per voter: display list, input + validate + store vote → tally → scan for most and least → output both.

Validation: three separate loopsTally: vote value = array indexTracking: maximum and minimum

❓ Guiding questions – think before revealing

Which bullets describe input, and which describe output?
Why does VoteCount[] need no input loop of its own?
What does “does not need to identify… equal most or least popular” save you?

Reveal suggested reasoning

Which bullets describe input, and which describe output? The second to fourth bullets are input: the two counts, the option strings and every vote. The last bullet is output: the most and least popular options with their counts. Everything in between is processing.

Why does VoteCount[] need no input loop of its own? It is derived data — every tally is counted from Votes[] after the votes are stored. It only needs initialising to zero, never reading from the user.

What does “does not need to identify… equal most or least popular” save you? Tie handling. A strict > comparison keeps the first maximum and a strict < keeps the first minimum, and the question says that is fully acceptable.

Reveal Cambridge pseudocode for Stage 1

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Initialise all three arrays
// Input and validate the number of options (2 to 12)
// Input and validate the number of voters (2 to 1000)
// Input each option into Options[]

FOR VoterCounter ← 1 TO NumberOfVoters
    // display the option list for this voter
    // input, validate and store this vote in Votes[]
NEXT VoterCounter

// tally VoteCount[] from Votes[]
// scan VoteCount[] for the most and least popular
// output both options with their counts

📖 Detailed explanation

“Between 2 and 12” and “between 2 and 1000” are the two validation ranges. They are different ranges for different inputs, so each count gets its own loop and its own error message.

“For each voter… display the list” puts a display loop inside the voter loop. The list is shown again for every voter, not once at the start.

“Once all the votes have been input” is a timing instruction: the tally must wait until the voter loop has finished.

“The array index represents the option number” tells you VoteCount[3] holds the tally for option 3. That is why the tally loop can use the stored vote directly as an index.

⚠️ Common mistakes

Tallying inside the vote-collecting loop, which ignores the question’s “once all the votes have been input” instruction.
Treating “validate” as a single IF — a rejected value must be asked for again, which needs a loop.
Forgetting one of the three arrays when initialising, most commonly Options[].
Outputting option numbers instead of the option texts stored in Options[].

💡 Exam hack / tip

Underline “between 2 and 12”, “between 2 and 1000”, “for each voter” and “once all the votes have been input”. Those phrases give the two validation loops, the nested display, and the two-pass structure.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · full requirement coverageR1–R5 · task order plannedAO3 · logical sequenceAO3 · comments explain purpose

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.

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. Options[], Votes[] and VoteCount[] are supplied by the question — your program must use them exactly, and must not declare them.
Add the two survey-size variables. NumberOfOptions bounds the option and display loops; NumberOfVoters bounds the voting and tally loops.
Add the counters and the vote holder. OptionCounter, VoterCounter and Index drive the loops; Vote holds the option number being entered before it is stored.
Add the four champion variables. MostVotes and MostOption remember the biggest tally, LeastVotes and LeastOption the smallest — counts and positions are kept separately.
Check for unnecessary data. No extra arrays are needed: VoteCount[] is the only derived array, and everything else is a simple variable.

Given: three 1D arraysNo declarations allowedFour champion variables

❓ Guiding questions – think before revealing

Why keep MostOption separate from MostVotes?
Why is Vote[] needed at all — why not input straight into Votes[]?
What bounds does each counter use?

Reveal suggested reasoning

Why keep MostOption separate from MostVotes? The output needs the option text, which lives in Options[MostOption]. Storing the position and the count separately makes that lookup trivial at the end.

Why is Vote[] needed at all — why not input straight into Votes[]? The value must be validated before it is stored. It is read into Vote, checked against 1 to NumberOfOptions, and only copied into Votes[VoterCounter] once it is legal. Writing invalid data into the array would corrupt the tally.

What bounds does each counter use? OptionCounter runs 1 to NumberOfOptions (never a hardcoded 12), VoterCounter runs 1 to NumberOfVoters, and Index is reserved for the initialisation loops over the declared maximum sizes.

Reveal Cambridge pseudocode for Stage 2

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Given by the question — do NOT declare, assume already set up:
// Options[]   : the option texts, indexed 1 to 12
// Votes[]     : one validated vote per user, indexed 1 to 1000
// VoteCount[] : votes per option, index = option number
//
// Working variables your program uses (also assumed declared):
// NumberOfOptions   NumberOfVoters
// OptionCounter     VoterCounter    Index
// Vote
// MostVotes   MostOption   LeastVotes   LeastOption

📖 Detailed explanation

The arrays are indexed from 1. Cambridge pseudocode is 1-based, and VoteCount[1] belongs to option 1 — there is no slot 0 to worry about.

VoteCount[] is indexed by option number. The question says so explicitly. That single sentence turns the counting pass into a one-line assignment per vote.

Scope follows purpose. The champion variables must survive the whole program; Vote is reused for every voter. Deciding that now prevents reset mistakes later.

⚠️ Common mistakes

Declaring the arrays and variables anyway — the question explicitly says not to, and the lines are wasted.
Renaming the arrays (Option[], UserVotes[]), which the mark scheme treats as not using the supplied structures.
Storing the most popular option’s text in a string variable during the scan instead of its position.
Reusing VoterCounter in the tally loop before the voting loop has finished with it.

💡 Exam hack / tip

Borrow the question’s own words for identifiers: NumberOfOptions, VoteCount, MostVotes, LeastOption. An examiner should map every variable back to a phrase in the question.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · appropriate data structuresR1–R5 · 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.

Initialise all three arrays

Give every element a known value before anything is used.

🧠 Step-by-step thinking

Initialise before any input. The bullet says “before they are used”, so the clearing loops run first, before the counts are even requested.
Use the declared maximum sizes. Options[] holds up to 12 options, Votes[] up to 1000 votes and VoteCount[] one slot per possible option. Clearing those maxima is always safe because the counts are not known yet.
Empty strings for text, zeros for numbers. Options[Index] ← "" clears an option slot; Votes[Index] ← 0 and VoteCount[Index] ← 0 clear numeric slots.
The VoteCount[] zeros are the ones that matter. An option nobody votes for must finish on a genuine 0 — the least-popular result depends on it.
One counter for the clearing loops. Index is reused by all three loops because they run one after another and never nest.

Once: before any inputMaxima: 12 and 1000Critical: VoteCount[] zeros

❓ Guiding questions – think before revealing

Why initialise to the maxima instead of NumberOfOptions and NumberOfVoters?
Why must VoteCount[] be zeroed rather than left alone?
Does Votes[] really need clearing if every slot is overwritten?

Reveal suggested reasoning

Why initialise to the maxima instead of NumberOfOptions and NumberOfVoters? At the top of the program neither count has been input yet, so the only sizes the program can trust are the declared maxima. (Zeroing VoteCount[1..NumberOfOptions] after validation is also credited, because the tally does not use the array until later.)

Why must VoteCount[] be zeroed rather than left alone? An array element that has never been assigned holds an unknown value. If option 4 receives no votes, nothing increments its slot, so the least-popular scan would compare against rubbish instead of 0.

Does Votes[] really need clearing if every slot is overwritten? Every slot 1 to NumberOfVoters is overwritten, yes — but the bullet says all the arrays, and clearing the declared 1000 slots makes that rule visible to the examiner.

Reveal Cambridge pseudocode for Stage 3

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Initialise all the arrays before they are used
FOR Index ← 1 TO 12
    Options[Index] ← ""       // clear every option slot
    VoteCount[Index] ← 0      // one counter per possible option
NEXT Index
FOR Index ← 1 TO 1000
    Votes[Index] ← 0          // clear every voter slot
NEXT Index

📖 Detailed explanation

“All the arrays” means all three. Options[], Votes[] and VoteCount[] each get a clearing pass — missing one loses the R1 requirement.

Initialisation is not declaration. The question forbids declarations but demands initialisation: the arrays exist already, and your job is to give every element a known value.

The empty string is the text equivalent of zero. Option slots hold strings, so they are cleared with ""; numeric slots are cleared with 0.

⚠️ Common mistakes

Initialising only VoteCount[] and forgetting the two storage arrays.
Looping Index to NumberOfOptions before that variable has been input and validated.
Clearing Options[] with 0 instead of "", mixing data types.
Nesting the three clearing loops inside each other instead of running them one after another.

💡 Exam hack / tip

Say it as a rule: clear first, count later. The examiner looks for a block of initialisation near the top of the answer — three small loops earn the whole requirement.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · correct starting stateR1 · all arrays initialisedAO3 · reliable logic

Initialisation supports AO2 because every array starts from a known state, and AO3 because the logic is reliable from the first line. These are alignment notes, not separately allocated marks.

Input the survey size and the options

Validate both counts with re-entry loops, then store each option.

R2 · R3

🧠 Step-by-step thinking

Validate with a loop, not an IF. A rejected count must be asked for again. REPEAT … UNTIL fits naturally: input, check, repeat until the value is in range.
Test both ends of each range. NumberOfOptions must satisfy >= 2 AND <= 12; NumberOfVoters must satisfy >= 2 AND <= 1000.
Show an error message on rejection. All outputs need suitable messages — including the one that tells the user what went wrong and what is expected.
Only then collect the options. The option loop runs 1 to NumberOfOptions, so it must wait until that value is valid.
Store straight into the array. INPUT Options[OptionCounter] puts each string directly into its slot — no extra variable is needed.

Range: 2 to 12 optionsRange: 2 to 1000 votersPrompt before every INPUT

❓ Guiding questions – think before revealing

Why REPEAT…UNTIL rather than WHILE…ENDWHILE?
What is wrong with testing only one end of the range?
Why can the option loop not run before the validation?

Reveal suggested reasoning

Why REPEAT…UNTIL rather than WHILE…ENDWHILE? The value must be read at least once before it can be tested, which is exactly the post-condition pattern REPEAT is for. A WHILE loop needs the variable pre-loaded before the first test.

What is wrong with testing only one end of the range? UNTIL NumberOfOptions <= 12 alone would accept 0 or a negative number. Both bounds must be checked together with AND.

Why can the option loop not run before the validation? Its bound is NumberOfOptions. Looping before the value is legal risks running to an unvalidated, possibly absurd bound.

Reveal Cambridge pseudocode for Stage 4

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Input and validate the number of options (2 to 12)
REPEAT
    OUTPUT "Enter the number of options (between 2 and 12): "
    INPUT NumberOfOptions
    IF NumberOfOptions < 2 OR NumberOfOptions > 12 THEN
        OUTPUT "Invalid - the number of options must be between 2 and 12"
    ENDIF
UNTIL NumberOfOptions >= 2 AND NumberOfOptions <= 12

// Input and validate the number of voters (2 to 1000)
REPEAT
    OUTPUT "Enter the number of voters (between 2 and 1000): "
    INPUT NumberOfVoters
    IF NumberOfVoters < 2 OR NumberOfVoters > 1000 THEN
        OUTPUT "Invalid - the number of voters must be between 2 and 1000"
    ENDIF
UNTIL NumberOfVoters >= 2 AND NumberOfVoters <= 1000

// Input each option into Options[]
FOR OptionCounter ← 1 TO NumberOfOptions
    OUTPUT "Enter option number ", OptionCounter, ": "
    INPUT Options[OptionCounter]
NEXT OptionCounter

📖 Detailed explanation

The error message mirrors the range. Telling the user “between 2 and 12” inside the IF means the next attempt is informed — that is what “suitable messages” rewards.

The UNTIL condition is the acceptance test. It is the exact opposite of the rejection test: >= 2 AND <= 12. Writing both keeps the loop and the message consistent.

The prompt is part of the input. OUTPUT before INPUT tells the user what to type — the question demands it for every input, options included.

⚠️ Common mistakes

Using IF alone, so a rejected count is never asked for again.
Accepting 1 option or 1 voter — the ranges start at 2, and a one-option survey cannot rank popularity.
Looping the option input with a hardcoded 12 instead of NumberOfOptions.
Forgetting the prompt OUTPUT before an INPUT.

💡 Exam hack / tip

Copy the pattern once and reuse it: prompt, input, reject with a message, repeat until in range. The two count validations and the vote validation are the same shape with different bounds.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · input validation loopsR2 · both counts validatedR3 · options storedAO3 · suitable messages

The validation loops supply the R2 evidence, and the error messages support the AO3 accuracy requirement. These are alignment notes, not separately allocated marks.

Display the options and collect every vote

Each voter sees the list, then inputs a validated option number.

🧠 Step-by-step thinking

Nest the display inside the voter loop. Each voter sees the list fresh: an inner FOR OptionCounter loop prints “number – option” lines, then the vote is read.
Validate against the live bound. The vote must be between 1 and NumberOfOptions — not 12. A survey with 4 options rejects 5, even though the array could hold 12.
Reject, then re-ask, in a loop. The same REPEAT … UNTIL pattern as the counts, with its own error message naming the valid range.
Store only validated votes. Votes[VoterCounter] ← Vote sits after the loop, so nothing illegal ever enters the array.
Keep the voter counter for the slot. VoterCounter is both the loop counter and the index where this voter’s vote is stored.

Display loop per voterTest: 1 to NumberOfOptionsStore after validation

❓ Guiding questions – think before revealing

Why display the list inside the voter loop rather than once at the start?
What happens to a vote of 0 or 7 when there are 4 options?
Why is Votes[VoterCounter] ← Vote after the REPEAT rather than inside it?

Reveal suggested reasoning

Why display the list inside the voter loop rather than once at the start? The bullet says “for each voter”. Displaying it every time also means every voter acts on the true current list — and it costs nothing but an inner loop.

What happens to a vote of 0 or 7 when there are 4 options? Either bound fails the UNTIL test, the error message prints, and the same voter is asked again. Only a value in 1–4 ever reaches Votes[].

Why is Votes[VoterCounter] ← Vote after the REPEAT rather than inside it? Inside the loop the value might still be invalid. After UNTIL succeeds, Vote is guaranteed legal, so that is the safe moment to store it.

Reveal Cambridge pseudocode for Stage 5

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Collect, validate and store every vote
FOR VoterCounter ← 1 TO NumberOfVoters
    // display the list of options for this voter
    FOR OptionCounter ← 1 TO NumberOfOptions
        OUTPUT OptionCounter, " - ", Options[OptionCounter]
    NEXT OptionCounter
    REPEAT
        OUTPUT "Voter ", VoterCounter, " - enter your preferred option number: "
        INPUT Vote
        IF Vote < 1 OR Vote > NumberOfOptions THEN
            OUTPUT "Invalid option - enter a number between 1 and ", NumberOfOptions
        ENDIF
    UNTIL Vote >= 1 AND Vote <= NumberOfOptions
    Votes[VoterCounter] ← Vote      // store the validated vote
NEXT VoterCounter

📖 Detailed explanation

Two loops, two different jobs. The outer loop counts voters; the inner loop prints options. The REPEAT is a third structure — it guards one voter’s single vote, it does not iterate voters.

The error message reuses the live bound. Printing NumberOfOptions in the message keeps it correct for any survey size between 2 and 12.

The validation protects the tally. Because only legal values enter Votes[], the counting pass can trust every element it reads — no second check needed.

⚠️ Common mistakes

Validating against 12 instead of NumberOfOptions, which accepts votes for options that do not exist.
Displaying the option list only once, before the voter loop, so later voters never see it.
Storing the vote before the UNTIL test succeeds, letting an invalid value into Votes[].
Using OptionCounter as the storage index — the slot belongs to the voter, not to the option.

💡 Exam hack / tip

The examiner’s checklist for this bullet is display, input, validate, store — in that order, for every voter. Four verbs, one nested structure.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · nested iteration and validationR3 · per-voter display and storageAO3 · correct live bounds

The voter loop is the clearest AO2 evidence of nesting and validation, and the live bounds support AO3 accuracy. These are alignment notes, not separately allocated marks.

Tally the votes and track both champions

One pass fills VoteCount[]; one scan finds the most and least popular.

🧠 Step-by-step thinking

Walk Votes[], not Options[]. One pass over the voters: each stored vote is the option number whose tally rises.
Use the vote as the index. VoteCount[Votes[VoterCounter]] ← VoteCount[Votes[VoterCounter]] + 1 reads the vote, then increments that option’s slot — no search, no IF chain.
Seed the champions before the scan. MostVotes ← -1 is below any count; LeastVotes ← NumberOfVoters + 1 is above any count, so the first option always takes both titles first.
Scan options 1 to NumberOfOptions. Every slot is compared twice: once against the most-popular tracker, once against the least-popular tracker.
Use strict comparisons. > and < keep the first of any tie — and the question says ties need not be identified.

Tally: one line per voteSeeds: -1 and NumberOfVoters + 1Strict > and <

❓ Guiding questions – think before revealing

Why does the tally need no IF statements?
Why seed LeastVotes with NumberOfVoters + 1?
Why is one scan enough for both champions?

Reveal suggested reasoning

Why does the tally need no IF statements? Every vote is a legal option number, guaranteed by the validation stage. So Votes[VoterCounter] can be dropped straight into the index — each pass increments exactly the right slot.

Why seed LeastVotes with NumberOfVoters + 1? No option can receive more than NumberOfVoters votes, so NumberOfVoters + 1 is guaranteed to be beaten. Seeding with 0 would break the moment an option receives no votes — exactly what happens to Zenith 5 in the sample.

Why is one scan enough for both champions? Each option’s count can be tested against both trackers in the same loop pass. Two separate scans would work but repeat the iteration.

Reveal Cambridge pseudocode for Stage 6

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Count the votes for each option
FOR VoterCounter ← 1 TO NumberOfVoters
    VoteCount[Votes[VoterCounter]] ← VoteCount[Votes[VoterCounter]] + 1
NEXT VoterCounter

// Find the most and least popular options
MostVotes ← -1
LeastVotes ← NumberOfVoters + 1
FOR OptionCounter ← 1 TO NumberOfOptions
    IF VoteCount[OptionCounter] > MostVotes THEN
        MostVotes ← VoteCount[OptionCounter]
        MostOption ← OptionCounter
    ENDIF
    IF VoteCount[OptionCounter] < LeastVotes THEN
        LeastVotes ← VoteCount[OptionCounter]
        LeastOption ← OptionCounter
    ENDIF
NEXT OptionCounter

📖 Detailed explanation

The double indexing is the heart of the question. Votes[VoterCounter] fetches a vote; that value then names the VoteCount[] slot to increment. Reading it as “the vote says which counter to raise” makes the line memorable.

The seeds guarantee a first champion. Because -1 and NumberOfVoters + 1 can never be genuine tallies, the first option scanned always overwrites both — even an option with 0 votes.

Champion updates are atomic. Each IF writes the count and the option number together; updating one without the other loses exactly what the output needs.

⚠️ Common mistakes

Writing VoteCount[VoterCounter] instead of VoteCount[Votes[VoterCounter]], tallying voters rather than options.
Seeding LeastVotes with 0, so an option with no votes can never become the least popular.
Scanning VoteCount[] up to 12 instead of NumberOfOptions, letting empty slots distort the result.
Updating MostVotes but not MostOption, leaving the output pointing at the wrong option.

💡 Exam hack / tip

Test the tally line by hand: voter 3 stored a 1, so VoteCount[1] rises. If your line cannot be read that way, the indexes are the wrong way round.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · counting and max/min trackingR4 · tally and championsAO3 · correct seeds and comparisons

This stage supplies the counting, selection and tracking evidence for AO2, and the seed choices support AO3 accuracy. These are alignment notes, not separately allocated marks.

Report the most and least popular options

Close the scan, look up both names, and output them with their counts.

🧠 Step-by-step thinking

Output after the scan. Both champions are final only when the option loop has finished, so the two OUTPUT lines sit after NEXT OptionCounter.
Look the names up through Options[]. Options[MostOption] and Options[LeastOption] convert the stored positions into the texts the voters actually saw.
Print the counts beside the names. The question asks for the options and the number of voters who selected each — so MostVotes and LeastVotes appear in the same lines.
Keep suitable messages. The words “Most popular” and “Least popular” are part of the output, not just the values.
Nothing else follows. The two lines are the last statements of the program — a quick check that nothing was left inside a loop by mistake.

Output: two linesLookup: Options[MostOption]Counts included

❓ Guiding questions – think before revealing

Why output Options[MostOption] rather than MostOption?
Why must the outputs wait until after NEXT OptionCounter?
How do you know the output is complete?

Reveal suggested reasoning

Why output Options[MostOption] rather than MostOption? MostOption is a position. The question asks for the option itself — the text the voters chose from — so the position must be translated through Options[].

Why must the outputs wait until after NEXT OptionCounter? Inside the loop the champions are still changing; outputting there would print a line per option. After the loop, each result is printed exactly once.

How do you know the output is complete? Check it against the bullet: the most popular option, the least popular option, and the number of voters who selected each — two lines, four facts.

Reveal Cambridge pseudocode for Stage 7

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

NEXT OptionCounter

// Output the most and least popular options with their counts
OUTPUT "Most popular: ", Options[MostOption], " with ", MostVotes, " votes"
OUTPUT "Least popular: ", Options[LeastOption], " with ", LeastVotes, " votes"

📖 Detailed explanation

Position becomes text at the last moment. Keeping positions in the trackers and looking up the text only for output is the cleanest use of the parallel arrays.

Both counts are required output. A response that prints the options without the counts answers only half of the final bullet.

The messages make the output self-explanatory. “Most popular:” and “Least popular:” satisfy the “suitable messages” closing line one last time.

⚠️ Common mistakes

Outputting MostOption as a bare number instead of looking up the option text.
Printing the results inside the scan loop, once per option.
Forgetting LeastVotes or MostVotes in the output lines.
Swapping the two trackers, crowning the least popular option as the winner.

💡 Exam hack / tip

End-of-question checklist: scan closed, names looked up, both counts printed, messages on every line. Four ticks in the margin protect the final output marks.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · complete outputsR5 · results with countsAO3 · accurate messages

The summary delivers the R5 outputs, and the accurate messages support AO3. 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 three arrays, the two validated counts and the two-pass structure.	Establishes logical order and comments plan.
2 · Data	Required data structures	Uses the given arrays plus counters, the vote holder and four champion variables.	Meaningful identifiers throughout; no declarations.
3 · Initialise	R1	Initialises Options[], Votes[] and VoteCount[] before use.	Clear comments and a reliable starting state.
4 · Setup	R2, R3	Validates 2–12 options and 2–1000 voters with re-entry loops; stores each option.	Correct range bounds and suitable error messages.
5 · Voting	R3	Displays the option list per voter and stores each validated vote in Votes[].	Vote checked against 1 to NumberOfOptions.
6 · Counting	R4	Tallies VoteCount[] from Votes[] and tracks the most and least popular.	Correct seeds (-1 and NumberOfVoters + 1) and strict comparisons.
7 · Summary	R5	Outputs both options with their counts after the scan.	Names looked up through Options[] and messages on every output.

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

QUESTION 9 · FULL PSEUDOCODECambridge 0478 style · 1-based indexing

// All arrays and variables are assumed declared, as the question instructs
// Initialise all three arrays before they are used
FOR Index ← 1 TO 12
    Options[Index] ← ""         // clear every option slot
    VoteCount[Index] ← 0        // one counter per possible option
NEXT Index
FOR Index ← 1 TO 1000
    Votes[Index] ← 0            // clear every voter slot
NEXT Index
// Input and validate the number of options (2 to 12)
REPEAT
    OUTPUT "Enter the number of options (between 2 and 12): "
    INPUT NumberOfOptions
    IF NumberOfOptions < 2 OR NumberOfOptions > 12 THEN
        OUTPUT "Invalid - the number of options must be between 2 and 12"
    ENDIF
UNTIL NumberOfOptions >= 2 AND NumberOfOptions <= 12
// Input and validate the number of voters (2 to 1000)
REPEAT
    OUTPUT "Enter the number of voters (between 2 and 1000): "
    INPUT NumberOfVoters
    IF NumberOfVoters < 2 OR NumberOfVoters > 1000 THEN
        OUTPUT "Invalid - the number of voters must be between 2 and 1000"
    ENDIF
UNTIL NumberOfVoters >= 2 AND NumberOfVoters <= 1000
// Input each option and store it in Options[]
FOR OptionCounter ← 1 TO NumberOfOptions
    OUTPUT "Enter option number ", OptionCounter, ": "
    INPUT Options[OptionCounter]
NEXT OptionCounter
// For every voter: display the option list, validate the vote, store it
FOR VoterCounter ← 1 TO NumberOfVoters
    FOR OptionCounter ← 1 TO NumberOfOptions
        OUTPUT OptionCounter, " - ", Options[OptionCounter]
    NEXT OptionCounter
    REPEAT
        OUTPUT "Voter ", VoterCounter, " - enter your preferred option number: "
        INPUT Vote
        IF Vote < 1 OR Vote > NumberOfOptions THEN
            OUTPUT "Invalid option - enter a number between 1 and ", NumberOfOptions
        ENDIF
    UNTIL Vote >= 1 AND Vote <= NumberOfOptions
    Votes[VoterCounter] ← Vote      // store the validated vote
NEXT VoterCounter
// Count the votes: each stored vote is the index of the option chosen
FOR VoterCounter ← 1 TO NumberOfVoters
    VoteCount[Votes[VoterCounter]] ← VoteCount[Votes[VoterCounter]] + 1
NEXT VoterCounter
// Find the most and least popular options in one scan of VoteCount[]
MostVotes ← -1                    // smaller than any possible count
LeastVotes ← NumberOfVoters + 1   // larger than any possible count
FOR OptionCounter ← 1 TO NumberOfOptions
    IF VoteCount[OptionCounter] > MostVotes THEN
        MostVotes ← VoteCount[OptionCounter]
        MostOption ← OptionCounter
    ENDIF
    IF VoteCount[OptionCounter] < LeastVotes THEN
        LeastVotes ← VoteCount[OptionCounter]
        LeastOption ← OptionCounter
    ENDIF
NEXT OptionCounter
OUTPUT "Most popular: ", Options[MostOption], " with ", MostVotes, " votes"
OUTPUT "Least popular: ", Options[LeastOption], " with ", LeastVotes, " votes"

Why this is a complete response

It covers the five mark-scheme requirements: all three arrays initialised before use (R1), validated counts for options and voters with re-entry loops (R2), option strings stored and every voter’s validated vote collected into Votes[] (R3), the VoteCount[] tally with most and least popular tracking (R4), and the final outputs with suitable messages (R5).

What to check before submitting

Check the three initialisation loops, the REPEAT…UNTIL ranges (2–12 and 2–1000), the vote test against 1 to NumberOfOptions, the VoteCount[Votes[VoterCounter]] tally, the champion seeds, and the comments explaining the program.

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 survey run.

Step through a sample vote. Watch the options being stored, see the invalid vote rejected and re-entered, follow the counting pass filling VoteCount[] slot by slot, and watch the most and least popular champions settle.

Last tab · Trace player

Sample input → expected results

One sample survey is shown with 4 options and 8 voters (the real question allows 2–12 options and 2–1000 voters). The sample deliberately tests a rejected vote — voter 6 first enters 7, which is outside 1–4, and re-enters 2 — and an option that receives no votes at all, so Zenith 5’s tally stays at its initialised 0 and becomes the least popular. These are illustrative values, not data supplied by the examination question.

Input arrays Options[] and Votes[]

Voter	First entry	Stored vote

Options[] for this survey: 1 Pine X20 · 2 Orbit S9 · 3 Nova One · 4 Zenith 5. The row number is the voter position used by Votes[].

Reveal expected per-voter results and survey summary

Expected per-voter results After validation and counting

Voter	First entry	Stored vote	Option chosen

Execution trace

Step 1 of 1

Initialisation

The program begins.

Program output so far

(No output yet)

Live variable values

Survey counters

Ready

Tip: use Next step slowly and watch VoterCounter, CurrentVote and the three counters. Nothing in VoteCount[] changes during the voting phase — the tally only fills in the counting pass.

Trace colours: blue row = current voter; amber cell = the vote currently being entered or tallied; orange cells = voters already processed.

Boundary examples: voter 6’s first entry fails because 7 > 4, so the REPEAT loop rejects it and asks again — only the re-entered 2 reaches Votes[6]. Zenith 5 receives no votes at all, so VoteCount[4] keeps its initialised 0 and becomes the least popular option. The champion trackers start at -1 and NumberOfVoters + 1 (= 9) so even that 0 beats the least-popular seed.

From blank arrays to the class’s most and least popular option.

Learning targets

01 · Understand

02 · Construct

03 · Complete

Read the whole question first

Before you move on

Decode the requirements

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Plan the data and identifiers

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Initialise all three arrays

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Input the survey size and the options

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Display the options and collect every vote

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Tally the votes and track both champions

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Report the most and least popular options

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

What does a high-level response look like?

How the seven stages contribute

Final self-check

Complete solution

Why this is a complete response

What to check before submitting

Visualisation: watch the survey run.

Sample input → expected results

Input arrays Options[] and Votes[]

Expected per-voter results After validation and counting

Execution trace

Initialisation

Live variable values

Survey counters