15-mark question lab · start here

From monthly litter weights to prizes and certificates.

Build the solution in a sensible order: understand the parallel arrays, input and validate each weight, sort both arrays descending in step, award the two heaviest pickers, then build the certificate list for every weight over 3 kilograms. Learn the reasoning before revealing the complete program.

1D parallel arraysInput validationDescending bubble sortTop-two selectionStrict > 3 boundary15 marks

Learning targets

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

Lesson overview

01 · Understand

Identify the two given arrays, their shared member index, the two-heaviest prize decided by the sort and the strict over-3-kilogram certificate rule.

02 · Construct

Input and validate every weight, then bubble sort PickedWeight[] and PickerName[] in parallel so every swap moves a name with its weight.

03 · Complete

Output Best in Group and Second best in Group, build PickerCertificate[] with its own counter, and report the number of certificates to print.

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 member index, the descending order of the sort and the strict over-three-kilogram boundary all affect the structure of your solution.

Question 12 · 15 marks

Cambridge IGCSE Computer Science · 0478/23 · Question 12

Members of a litter picking group complete a litter pick every month. Members’ names are stored in one-dimensional (1D) array PickerName[].
Each member stores the weight of the litter they have picked in another one-dimensional (1D) array PickedWeight[].
The weights are in kilograms with one decimal place, for example 8.4.
The position of each member’s data in the two arrays is the same. For example, the member stored at index 10 in PickerName[] and at index 10 in PickedWeight[] is the same.

Every month, there is a small prize awarded to the members of the group who have the two heaviest weights. Certificates are awarded to all members with a pick weight of over three kilograms.

Write a program that meets the following requirements:

allows the weight of members’ picks to be input and validated
sorts the arrays PickedWeight[] and PickerName[] in descending order of weight
outputs the member names and the pick weights of the members with the two heaviest picks and identifies them as “Best in Group” and “Second best in Group”
stores the names of all the members who will receive a certificate in the array PickerCertificate[]
outputs a message stating the number of certificates to be printed.

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.

You do not need to initialise the data in the array PickerName[]

Before you move on

These are the five required techniques identified by the Cambridge mark scheme.

Mark-scheme map

Input every member’s pick weight with a suitable message and validate it before the value is accepted.

Sort PickedWeight[] and PickerName[] in parallel into descending order of weight, keeping each name with its weight.

Output the top two names and weights with the labels “Best in Group” and “Second best in Group”.

Store the name of every member with a weight over three kilograms in PickerCertificate[].

Output a message stating the number of certificates to be printed.

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

List the five bullets as tasks. The program must input and validate weights, sort both arrays descending, output the top two with their labels, build PickerCertificate[], then output the certificate count — five tasks, in that order.
Spot the parallel-array rule. PickerName[] and PickedWeight[] share one index, so the sort must move a name and its weight as one block — sorting the weights alone would award the prize to the wrong member.
Notice what the program builds. PickerCertificate[] is not given data — the program fills it with the names of every member whose pick weighs over three kilograms, so it needs its own counter.
Translate the command words. “Input and validated” means a repeat-until loop with a message; “descending order” means largest first; “identifies them as” means the labels “Best in Group” and “Second best in Group” appear in the output; “over three kilograms” means a strict > 3 test.
Build the order. input loop (validate every weight) → descending parallel sort → top-two outputs → certificate loop with its own counter → count message.

Input: REPEAT UNTIL validationSort: descending and parallelCertificates: strict > 3Output: top two + count

❓ Guiding questions – think before revealing

How many members are there?
Why does the sort come before the outputs?
What exactly must be validated?

Reveal suggested reasoning

How many members are there? The question never says — it only names the arrays. The solution loops to a given value MemberCount, assumed set up alongside the arrays; the technique is identical for 6 members or 60.

Why does the sort come before the outputs? The two heaviest weights are positions 1 and 2 only after the descending sort, and the certificate names are read from the sorted array too — every later task consumes the sorted arrays.

What exactly must be validated? Each weight as it is input. A pick weight must be positive, so the loop rejects zero and negative values and asks again — with a message, as the closing lines demand.

Reveal Cambridge pseudocode for Stage 1

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Task 1 - input and validate every weight
FOR MemberCounter ← 1 TO MemberCount
    REPEAT
        // prompt, input, reject with a message if <= 0
    UNTIL PickedWeight[MemberCounter] > 0
NEXT MemberCounter

// Task 2 - sort both arrays descending by weight
// every swap moves a name with its weight

// Task 3 - output positions 1 and 2 with their labels
// Task 4 - build PickerCertificate[] (strict > 3)
// Task 5 - output the certificate count

📖 Detailed explanation

“Input and validated” is one bullet but two jobs: a prompt with a suitable message, and a loop that refuses to continue until the value is acceptable.

“Descending order of weight” fixes the sort direction: after sorting, position 1 holds the heaviest pick — which is exactly why the top-two output needs no searching afterwards.

“Identifies them as…” means the labels are part of the output, not separate lines: the marker looks for “Best in Group” and “Second best in Group” beside the right name and weight.

“Stores the names… in the array” forbids just printing the certificate winners — the names must be written into PickerCertificate[], which needs its own filling counter.

⚠️ Common mistakes

Reading only the first paragraph and missing that PickerCertificate[] must be built, not just counted.
Sorting PickedWeight[] alone, which separates every name from its weight and corrupts both prizes.
Treating “over three kilograms” as >= 3, which wrongly awards a certificate at exactly 3.0.
Forgetting that the weights are input by the program — unlike PickerName[], PickedWeight[] is not pre-loaded.

💡 Exam hack / tip

Underline “descending order of weight”, “the two heaviest”, “over three kilograms” and “the number of certificates to be printed”. Those phrases decide the sort direction, the podium positions, the strict boundary and the final message.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · algorithm designR1–R5 · full requirement coverageAO3 · logical orderAO3 · 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. PickerName[], PickedWeight[] and PickerCertificate[] are named by the question — the program must use them exactly, and PickerName[] arrives already filled.
Add the loop counters. MemberCounter walks the input and certificate loops; Index compares adjacent positions inside the sort.
Add the swap temporaries. TempWeight and TempName hold one element of each array while a pair is swapped — two arrays, two temporaries.
Add the certificate counter. CertCount counts how many names have been stored; it is also the index of the next free slot in PickerCertificate[].
Check for unnecessary data. No totals, averages or champion trackers are needed — the sort does the ranking, so nothing else has to survive between stages.

Given: PickerName[] and PickedWeight[]Built: PickerCertificate[]Counters and two swap temporaries

❓ Guiding questions – think before revealing

Why does CertCount double as the next free slot?
Why two temporaries?
Does the program need MemberCount?

Reveal suggested reasoning

Why does CertCount double as the next free slot? Because it starts at 0 and only increments when a name is stored: after k increments, k names occupy slots 1 to k, so slot CertCount + 1 is next. One counter, no gaps.

Why two temporaries? A swap must not overwrite a value it still needs. TempWeight frees PickedWeight[Index], then the name swap repeats the trick with TempName — skipping the name swap desynchronises the arrays.

Does the program need MemberCount? Yes — every loop needs an upper bound, and the question does not state one. MemberCount is assumed to be set up with the arrays, exactly as the closing lines allow.

Reveal Cambridge pseudocode for Stage 2

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Declarations are not required - the question says they can be assumed.
// This is the working set the program uses:

// MemberCounter - walks the input and certificate loops
// Index         - compares adjacent positions in the sort
// TempWeight    - holds a weight during a swap
// TempName      - holds a name during a swap
// CertCount     - counts certificates; indexes PickerCertificate[]

// Given and already set up:
// PickerName[]  PickerCertificate[]  MemberCount
// PickedWeight[] - filled by the input stage

📖 Detailed explanation

Parallel arrays live and die together. Every loop that touches PickedWeight[] uses the same PickerName[] index — that single rule keeps the pairing the question depends on.

The weights are REAL values. One decimal place, “for example 8.4”, means fractional weights, so no integer truncation anywhere in the program.

PickerCertificate[] grows from slot 1. Nothing pre-fills it: the certificate loop writes slot CertCount each time a qualifier is found, so the array is compact by construction.

⚠️ Common mistakes

Declaring a brand-new array for the sorted data instead of sorting PickedWeight[] in place.
Renaming the given arrays, which the mark scheme treats as ignoring the supplied data.
Using one temporary for both arrays, or forgetting the name swap entirely.
Adding a maximum-tracking champion to find the heaviest — the sort already ranks the array, so a champion pass is redundant work.

💡 Exam hack / tip

Borrow the question’s own words for identifiers: PickerName, PickedWeight, PickerCertificate, CertCount. An examiner should be able to 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 what the program builds

Start the certificate counter; leave the given data alone.

R4 · R5

🧠 Step-by-step thinking

Initialise the certificate counter once. CertCount ← 0 must run before the certificate loop — never inside it, or every pass would forget the names already stored.
Leave PickerName[] alone. The closing lines say the data in PickerName[] needs no initialising — it is already stored, and the sort will rearrange it in place.
Plan where PickedWeight[] is filled. Its values arrive from the validated input stage, one per member — there is nothing to initialise there either.
PickerCertificate[] starts conceptually empty. No pre-filling is needed: slot 1 is written when the first over-3-kilogram name is found, because CertCount increments before it stores.
Decide the validation rule now. A pick weight must be positive, so the reject test is PickedWeight[MemberCounter] <= 0 — decide it before writing the input loop.

Once: CertCount ← 0Never: initialising PickerName[]Reject test: <= 0

❓ Guiding questions – think before revealing

What goes wrong if CertCount ← 0 sits inside the certificate loop?
Does PickedWeight[] need initialising before the input loop?
Should the program clear PickerCertificate[] first?

Reveal suggested reasoning

What goes wrong if CertCount ← 0 sits inside the certificate loop? Every pass resets the count to 0, so slot 1 is rewritten by every qualifying member and only the last over-3-kilogram name survives — and the final count message would read 1.

Does PickedWeight[] need initialising before the input loop? No. Each element is written by a validated INPUT before it is ever read, and the REPEAT UNTIL loop guarantees the stored value is positive.

Should the program clear PickerCertificate[] first? It gains nothing: the array is only ever read up to CertCount, and the question only asks for names to be stored and the count to be output. Filling slots 1 to CertCount is enough.

Reveal Cambridge pseudocode for Stage 3

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Nothing in the given arrays needs initialising:
// PickerName[] already stores the members' names (the question says so)
// PickedWeight[] is filled by the input stage
// PickerCertificate[] is filled slot by slot after the sort

// The only value this program must start off itself:
CertCount ← 0   // no certificates counted yet

📖 Detailed explanation

“Once” versus “every pass” decides placement: CertCount belongs to the whole certificate stage, so it is set once, immediately before the loop that uses it.

The question removes work deliberately. “You do not need to initialise the data in the array PickerName[]” tells you the names are pre-stored — writing an initialising loop for them wastes time and can look like misunderstanding.

A counter is its own initialisation. Because CertCount counts before it stores, PickerCertificate[] needs no null-filling: unused slots are simply never addressed.

⚠️ Common mistakes

Resetting CertCount inside the certificate loop, so only the last qualifier is stored.
Writing a loop to initialise PickerName[] with nulls, ignoring the closing lines.
Assuming PickedWeight[] arrives pre-loaded like PickerName[], and skipping the input stage.
Leaving CertCount uninitialised and relying on it starting at zero by luck.

💡 Exam hack / tip

Sort the question’s arrays into three piles: given (PickerName[]), filled by input (PickedWeight[]) and built by the program (PickerCertificate[]). Only the third pile needs a starting value, and that value is CertCount ← 0.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · correct starting stateR4 · R5 · counter starts at zeroAO3 · reliable logic

Initialisation supports AO2 because the counter can genuinely drive the built array, and AO3 because the logic starts from a reliable state. These are alignment notes, not separately allocated marks.

Input and validate every weight

A repeat-until loop that refuses zero and negative weights.

🧠 Step-by-step thinking

Loop over every member. FOR MemberCounter ← 1 TO MemberCount visits each array position once, and the prompt names the member through PickerName[MemberCounter].
Input straight into the array. INPUT PickedWeight[MemberCounter] stores the weight at the member’s own position — no extra variable is needed.
Reject with a message, then repeat. The IF prints “Invalid weight…” when the value is zero or negative; the UNTIL test keeps the user inside the loop until a positive weight arrives.
Keep the message in the prompt. The closing lines require suitable messages on every input and output — “in kilograms” and the member’s name do that job.
One decimal place is data, not validation. The weights are REAL values such as 8.4; the validation checks positivity, not the number of decimal places.

REPEAT … UNTIL weight > 0INPUT into PickedWeight[]Message on every rejection

❓ Guiding questions – think before revealing

Why REPEAT UNTIL rather than WHILE?
Why test <= 0 in the message but > 0 in the UNTIL?
Could the validation use a range instead?

Reveal suggested reasoning

Why REPEAT UNTIL rather than WHILE? The weight must be input at least once before it can be tested, which is the post-condition pattern: REPEAT runs the body first, and UNTIL repeats until PickedWeight[MemberCounter] > 0 becomes TRUE.

Why test <= 0 in the message but > 0 in the UNTIL? The two tests are logical partners: anything zero or below earns the error message, and the loop can only end when the stored value is strictly positive. Writing only one of the pair leaves a rejection unexplained or the loop unable to stop.

Could the validation use a range instead? Yes — a sensible upper bound is also accepted by markers, as long as a message asks again and the loop cannot end on an invalid value. Positivity alone is the minimum the bullet demands.

Reveal Cambridge pseudocode for Stage 4

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

FOR MemberCounter ← 1 TO MemberCount
    REPEAT
        OUTPUT "Enter the weight picked by ",
            PickerName[MemberCounter], " in kilograms: "
        INPUT PickedWeight[MemberCounter]
        IF PickedWeight[MemberCounter] <= 0
        THEN
            OUTPUT "Invalid weight - please enter a value greater than zero"
        ENDIF
    UNTIL PickedWeight[MemberCounter] > 0
NEXT MemberCounter

📖 Detailed explanation

The shared index does double duty. The same MemberCounter fetches the prompt’s name from PickerName[] and chooses the storage slot in PickedWeight[] — the parallel-array rule in action.

The error message is part of the loop, not an afterthought. Without it the user re-enters a weight with no idea why; the closing lines make suitable messages a marked requirement.

Validation happens before the sort, not after. A rejected value never reaches the array, so every later stage — sort, podium, certificates — works on clean data.

⚠️ Common mistakes

Accepting the first value without any test, leaving the bullet’s “validated” unearned.
Testing PickedWeight[MemberCounter] >= 0, which accepts a zero weight as if a member could pick nothing and still be counted.
Putting the INPUT outside the REPEAT loop, so a rejected value is never re-entered.
Forgetting the prompt message, or prompting without naming the member whose weight is wanted.

💡 Exam hack / tip

Say the loop aloud: prompt, input, reject, repeat until positive. If any of those four words is missing from your code, one mark of R1 is missing with it.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · input with validation loopR1 · every weight validatedAO3 · suitable messages

The input loop is the clearest AO2 evidence of iteration with validation, and the messages are AO3 communication evidence. These are alignment notes, not separately allocated marks.

Sort both arrays descending, in parallel

A bubble sort whose every swap moves a name with its weight.

🧠 Step-by-step thinking

Choose a bubble sort. The classic Cambridge sort: repeated passes compare adjacent positions and swap when a pair is out of order — here, when the left weight is smaller than the right, so the heaviest bubbles up to position 1.
Make every swap parallel. Inside the same THEN branch, swap PickedWeight[Index] with PickedWeight[Index + 1] and PickerName[Index] with PickerName[Index + 1] — six lines, two temporaries.
Shrink each pass. FOR PassCounter ← 1 TO MemberCount - 1 with an inner bound of MemberCount - PassCounter: after each pass the heaviest remaining weight is settled at the top, so the compared region shrinks.
Check the direction twice. Descending means the largest weight ends at position 1, so the swap test is < — an ascending test would crown the lightest picker.
Ties stay in order. The strict < leaves equal weights unswapped, so if two pickers tie for heaviest, the earlier member keeps the higher position.

Descending: test is <Parallel swap: 6 linesShrinking bound per pass

❓ Guiding questions – think before revealing

Why must the name swap sit inside the same IF?
Why compare PickedWeight[Index] < PickedWeight[Index + 1]?
Is a swapped-flag version acceptable?

Reveal suggested reasoning

Why must the name swap sit inside the same IF? The two arrays are only parallel while every swap moves both. If the names were rearranged in a separate loop, they would drift out of step with the weights and the prize would go to whoever the broken arrays happened to line up.

Why compare PickedWeight[Index] < PickedWeight[Index + 1]? A pair is out of order for descending order exactly when the left value is smaller than the right; swapping then pushes bigger values towards position 1 on every pass.

Is a swapped-flag version acceptable? Yes — a REPEAT UNTIL Swapped = FALSE version earns the same marks. Pick one structure, write it correctly, and make sure the comparison direction still gives descending order.

Reveal Cambridge pseudocode for Stage 5

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

FOR PassCounter ← 1 TO MemberCount - 1
    FOR Index ← 1 TO MemberCount - PassCounter
        IF PickedWeight[Index] < PickedWeight[Index + 1]
        THEN
            TempWeight ← PickedWeight[Index]
            PickedWeight[Index] ← PickedWeight[Index + 1]
            PickedWeight[Index + 1] ← TempWeight
            TempName ← PickerName[Index]
            PickerName[Index] ← PickerName[Index + 1]
            PickerName[Index + 1] ← TempName
        ENDIF
    NEXT Index
NEXT PassCounter

📖 Detailed explanation

The two FOR headers are one decision. MemberCount - 1 passes with a bound of MemberCount - PassCounter is the standard shrinking bubble sort — after pass k, the last k positions hold the k lightest weights in order.

Six swap lines, two temporaries. Weights swap with TempWeight, names with TempName, inside one THEN branch — the pair travels as a block.

After the sort, position 1 is the answer. The podium and the certificate scan both read the sorted arrays; nothing about the sort’s result needs recomputing.

⚠️ Common mistakes

Writing the classic ascending test >, producing the lightest picker at position 1.
Swapping the weights but not the names, or vice versa — the parallel arrays desynchronise.
Swapping without temporaries, so PickedWeight[Index] is overwritten before it is copied.
Looping the inner FOR to MemberCount, which reads PickedWeight[MemberCount + 1] — one past the array.

💡 Exam hack / tip

Write the swap as a six-line block and comment it once: // keep every name with its weight. Then point at the comparison and ask: does position 1 finish as the heaviest? If not, flip the operator.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · sorting with parallel arraysR2 · descending order of weightAO3 · paired swaps stay in step

The sort supplies the main AO2 evidence for this question, and correctly paired swaps are the AO3 accuracy evidence. These are alignment notes, not separately allocated marks.

Output Best in Group and Second best in Group

Read the podium straight off the sorted arrays.

🧠 Step-by-step thinking

Read the podium straight off the array. After the descending sort, PickedWeight[1] is the heaviest pick and PickedWeight[2] the second heaviest — no search or comparison is needed.
Output name and weight together. Each line pairs PickerName[1] with PickedWeight[1], then PickerName[2] with PickedWeight[2] — the shared index does the matching.
Include the exact labels. The bullet says the members are identified as “Best in Group” and “Second best in Group” — those strings belong in the OUTPUT lines.
Keep the messages suitable. Say what each value is: name, label, weight in kilograms — markers read the OUTPUT strings as part of the answer.
Do this once, after the sort. The two outputs sit after the sorting loops, not inside them — two lines in total, printed once.

Positions 1 and 2Labels inside the messageNames via PickerName[]

❓ Guiding questions – think before revealing

Why is no maximum search needed here?
What if two members tie for heaviest?
Why output the unit in the message?

Reveal suggested reasoning

Why is no maximum search needed here? The descending sort has already ranked every member; positions 1 and 2 are the two heaviest by construction. Searching again would repeat the sort’s work and add bug risk.

What if two members tie for heaviest? The strict < in the sort keeps the earlier member at position 1, so the labels still attach to two real members — the sample avoids the tie, but the code handles it without changes.

Why output the unit in the message? The bullet asks for names and pick weights with suitable messages; naming the kilograms makes the output unambiguous and earns the communication credit.

Reveal Cambridge pseudocode for Stage 6

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// The sort has finished, so position 1 holds the heaviest pick
OUTPUT PickerName[1], " is Best in Group with ",
    PickedWeight[1], " kilograms"
OUTPUT PickerName[2], " is Second best in Group with ",
    PickedWeight[2], " kilograms"

📖 Detailed explanation

The sort is the search. This is the payoff of R2: ranking the whole array means the champion values need only be looked up, not hunted for with IF tests.

Indexes are positions, not names. PickerName[1] converts position 1 into the member the question asks you to print — outputting the number 1 instead would answer a different question.

Two lines, two labels, once each. The mark scheme lists both labels; each appears exactly once, attached to the right name and weight.

⚠️ Common mistakes

Outputting PickedWeight[0] and PickedWeight[1] — Cambridge arrays start at 1.
Printing only the names, or only the weights, when the bullet asks for both.
Missing one of the two exact labels, which the mark scheme lists word for word.
Leaving these outputs inside the sort loop, printing the podium once per pass.

💡 Exam hack / tip

Treat positions 1 and 2 as pre-paid answers: the sort has already paid for them. If you find yourself writing another IF to find the maximum, delete it — the array is already in descending order.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · outputs from sorted dataR3 · both labels with name and weightAO3 · accurate index use

The podium outputs are the R3 evidence, and reading them through the shared index is AO3 accuracy evidence. These are alignment notes, not separately allocated marks.

Build PickerCertificate[] and output the count

A strict over-3 test, an own counter, one final message.

R4 · R5

🧠 Step-by-step thinking

Scan the sorted array once. FOR MemberCounter ← 1 TO MemberCount visits every position; because the array is sorted, all the over-3-kilogram names sit in a leading block.
Test strictly over three. IF PickedWeight[MemberCounter] > 3 — a weight of exactly 3.0 is not over three kilograms and must be skipped.
Advance the counter before storing. CertCount ← CertCount + 1 then PickerCertificate[CertCount] ← PickerName[MemberCounter] packs qualifiers into slots 1, 2, 3… with no gaps.
Never use MemberCounter as the slot. Positions and certificates diverge at the first non-qualifier — the own counter is what keeps the array compact.
Output the count after the loop. OUTPUT CertCount, " certificates to be printed" runs once, when CertCount is final.

Strict test: > 3Own counter: CertCountCount message after the loop

❓ Guiding questions – think before revealing

Why > 3 and not >= 3?
Why does the loop still visit positions below the boundary?
What does the final output need?

Reveal suggested reasoning

Why > 3 and not >= 3? “Over three kilograms” means strictly greater, so 3.0 exactly fails the test. The sample’s 3.0-kilogram pick is there to catch the >= slip.

Why does the loop still visit positions below the boundary? It need not stop early, and stopping early adds an extra condition to get wrong. Letting the loop run to MemberCount means the test alone decides every slot — the simplest correct logic.

What does the final output need? A message stating the number of certificates to be printed: CertCount with the words “certificates to be printed”, output once after the loop finishes.

Reveal Cambridge pseudocode for Stage 7

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

CertCount ← 0
FOR MemberCounter ← 1 TO MemberCount
    IF PickedWeight[MemberCounter] > 3
    THEN
        CertCount ← CertCount + 1
        PickerCertificate[CertCount] ← PickerName[MemberCounter]
    ENDIF
NEXT MemberCounter

OUTPUT CertCount, " certificates to be printed"

📖 Detailed explanation

The sorted order makes the boundary visible. Qualifiers fill positions 1 to CertCount, then the first weight of 3.0 or less fails the test — the array itself shows where the certificates stop.

Two counters, two different jobs. MemberCounter says which member is being tested; CertCount says how many names have been stored. They start equal but diverge at the first non-qualifier.

The count message is a required output. R5 asks for a message stating the number — a bare number with no words is not a message, and outputting it inside the loop prints it once per member.

⚠️ Common mistakes

Using >= 3, which hands a certificate to a picker at exactly 3.0 kilograms.
Storing PickerCertificate[MemberCounter] ← PickerName[MemberCounter], leaving gaps where non-qualifiers sit.
Counting with CertCount but forgetting to store the names — the bullet demands both.
Outputting the count inside the loop, printing the message once per member instead of once.

💡 Exam hack / tip

Boundary drill: write the test as PickedWeight[MemberCounter] > 3 and say “over three” aloud. Then check the sample: the 3.0 pick must earn nothing, and CertCount must finish at the number of names actually stored.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · selection with own counterR4 · R5 · store then countAO3 · strict boundary and final message

The certificate loop delivers the R4 storage and the R5 message, and the strict boundary is 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 input + validation, parallel descending sort, labelled top two, built certificate array and count.	Establishes the order of the five tasks and the comment plan.
2 · Data	Required data structures	Given arrays plus MemberCounter, Index, two temporaries and CertCount.	Meaningful identifiers; MemberCount assumed set up.
3 · Initialise	R4, R5	CertCount starts at zero; PickerCertificate[] built from slot 1.	PickerName[] untouched, exactly as the closing lines allow.
4 · Validate	R1	REPEAT UNTIL loop re-asks until the weight is greater than zero.	Suitable prompt naming the member and the unit.
5 · Sort	R2	Parallel bubble sort, MemberCount − 1 passes, comparing < for descending.	Every swap moves a name and its weight together.
6 · Top two	R3	Outputs positions 1 and 2 with “Best in Group” and “Second best in Group”.	Names and weights read through the shared index.
7 · Awards	R4, R5	Strict > 3 test fills PickerCertificate[]; count message after the loop.	CertCount drives both the slot and the final message.

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 12 · FULL PSEUDOCODECambridge 0478 style · 1-based indexing

// Declarations are assumed - the question says none are needed.
// Given: PickerName[] (already stored), PickerCertificate[], MemberCount
// PickedWeight[] is filled by the input stage below.

// ---- R1: input and validate every member's pick weight ----
FOR MemberCounter ← 1 TO MemberCount
    REPEAT
        OUTPUT "Enter the weight picked by ",
            PickerName[MemberCounter], " in kilograms: "
        INPUT PickedWeight[MemberCounter]
        IF PickedWeight[MemberCounter] <= 0
        THEN
            OUTPUT "Invalid weight - please enter a value greater than zero"
        ENDIF
    UNTIL PickedWeight[MemberCounter] > 0
NEXT MemberCounter

// ---- R2: sort both arrays into descending order of weight ----
// A bubble sort with a shrinking bound. The comparison is < so the
// heaviest weight finishes at position 1. Every weight swap carries the
// matching name swap, keeping the parallel arrays in step.
FOR PassCounter ← 1 TO MemberCount - 1
    FOR Index ← 1 TO MemberCount - PassCounter
        IF PickedWeight[Index] < PickedWeight[Index + 1]
        THEN
            TempWeight ← PickedWeight[Index]
            PickedWeight[Index] ← PickedWeight[Index + 1]
            PickedWeight[Index + 1] ← TempWeight
            TempName ← PickerName[Index]
            PickerName[Index] ← PickerName[Index + 1]
            PickerName[Index + 1] ← TempName
        ENDIF
    NEXT Index
NEXT PassCounter

// ---- R3: output the two heaviest with their prize labels ----
OUTPUT PickerName[1], " is Best in Group with ",
    PickedWeight[1], " kilograms"
OUTPUT PickerName[2], " is Second best in Group with ",
    PickedWeight[2], " kilograms"

// ---- R4: store certificate names - strictly over 3 kilograms ----
CertCount ← 0
FOR MemberCounter ← 1 TO MemberCount
    IF PickedWeight[MemberCounter] > 3
    THEN
        CertCount ← CertCount + 1
        PickerCertificate[CertCount] ← PickerName[MemberCounter]
    ENDIF
NEXT MemberCounter

// ---- R5: output how many certificates to print ----
OUTPUT CertCount, " certificates to be printed"

Why this is a complete response

It covers the five mark-scheme requirements: every weight input with validation and suitable messages (R1), a parallel bubble sort putting both arrays in descending order of weight (R2), the two heaviest pickers output with the labels “Best in Group” and “Second best in Group” (R3), the over-3-kilogram names stored in PickerCertificate[] with its own counter (R4), and the certificate-count message (R5).

What to check before submitting

Check the REPEAT UNTIL validation, the strict < comparison that makes the sort descending, the paired name-and-weight swaps, the strict > 3 certificate test, the own counter on PickerCertificate[], 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 program work.

Step through a sample month. Watch the weights arrive and get validated, the parallel bubble sort drag the heaviest pick to the top, the two prizes leave the podium, and the certificate counter stop dead at the 3-kilogram boundary.

Last tab · Trace player

Sample input → expected results

Six sample pickers record one monthly weight in kilograms (MemberCount = 6; the real group size is not stated by the question, so the sample is scaled to 6 to keep the trace readable). The sample deliberately tests: Wei, whose first attempt of −2.5 fails the greater-than-zero validation and is re-entered as 5.2; Oliver’s pick of exactly 3.0 kilograms, which earns no certificate because “over three kilograms” is a strict test; and a descending bubble sort traced comparison by comparison, ending with Priya as Best in Group (8.4) and Tomasz as Second best in Group (6.1). These are illustrative values, not data supplied by the examination question.

Input arrays PickerName[] (given) and PickedWeight[] (input and validated)

Member	PickedWeight[] (kg)

The row number is the array position shared by PickerName[] and PickedWeight[] before the sort. Wei’s row shows his rejected first attempt — the trace re-enters his weight.

Reveal expected sorted results and group awards

Expected results After the sort, in descending order of weight

Place	PickerName[]	PickedWeight[] (kg)	Certificate

Execution trace

Step 1 of 1

Initialisation

The program begins.

Program output so far

(No output yet)

Live variable values

Group counters

Ready

Tip: use Next step slowly and watch MemberCounter during input and certificates, Index and SortPass during the sort, and CertCount as the 3-kilogram boundary decides each slot.

Trace colours: blue row = current member or compared pair; amber cell = the value being entered, compared or tested; green cells = work already completed.

Boundary example: Oliver’s sorted position is 5 with a pick of exactly 3.0 kilograms, and the certificate test is PickedWeight[MemberCounter] > 3 — 3.0 > 3 is FALSE, so he receives no certificate while Mariam’s 4.7 does. Sort example: Mariam’s 4.7 is smaller than Wei’s 5.2, so the strict test 4.7 < 5.2 swaps the pair — weight and name moving together.

From monthly litter weights to prizes and certificates.

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 what the program builds

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Input and validate every weight

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Sort both arrays descending, in parallel

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Output Best in Group and Second best in Group

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Build PickerCertificate[] and output the count

🧠 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 program work.

Sample input → expected results

Input arrays PickerName[] (given) and PickedWeight[] (input and validated)

Expected results After the sort, in descending order of weight

Execution trace

Initialisation

Live variable values

Group counters