Computer Science 9618/21 — May/June 2025

Background Concept

An identifier table is a design tool used before or during program development. It lists important data items used in a program and usually shows things such as the variable name, its purpose, and its data type.

The key idea is that each identifier should:

• have a meaningful name
• store one clear kind of data
• use a suitable data type

Typical data types here are:

• STRING for text such as names or categories
• DATE for dates
• REAL for decimal values such as money
• BOOLEAN for TRUE/FALSE values

Understanding the Question

You are given four example values from a stock-control system and must complete the missing parts of the identifier table.

For each row, you need to decide:

• a sensible variable name
• the correct data type

The variable name does not have to be one exact word from the mark scheme in real exams, but it must clearly match the purpose given in the explanation.

Approach

Work through each example value and ask two questions:

1. What kind of data is this?
2. What would be a clear variable name for it?

For example, if the value is text like "Fruit", that suggests a STRING. If the value is TRUE, that suggests a BOOLEAN.

Step-by-Step Reasoning

• "Fruit" is text. It represents a stock category, so a suitable name is Category. Text data uses the type STRING.
• 20/02/2025 is a calendar date. It tells us when an item was sold, so DateSold is a suitable name. The correct type is DATE.
• 12.67 has a decimal point, so it is not an integer. It represents a price or cost, so Cost is a suitable variable name. Decimal numeric data uses REAL.
• TRUE is one of the two Boolean values. It shows whether an item is in stock, so InStock is a clear name. The type is BOOLEAN.

The important point is not the exact wording of the variable name, but that it is meaningful and matches the data stored.

Key Takeaways

• Use identifier tables to plan variables clearly.
• Pick variable names that describe the data purpose.
• Match the example value to the correct data type.
• STRING, DATE, REAL, and BOOLEAN are all common choices in design questions.

Common Mistakes

• Using vague names such as x or data, which do not describe the purpose.
• Writing INTEGER for 12.67; decimals need REAL.
• Writing STRING for TRUE; TRUE and FALSE are BOOLEAN values.
• Treating a date as a number just because it contains digits.

Things to Be Careful About

• The variable name should match the explanation, not just the example value.
• Money values usually need REAL because they can contain decimal places.
• A Boolean field should describe a yes/no condition, such as InStock.
• If your centre has been taught slightly different naming conventions, that is fine as long as the name is sensible and the data type is correct.

Background Concept

In Paper 2, three of the most important programming constructs are:

• assignment: storing a value in a variable
• selection: choosing between alternatives based on a condition
• iteration: repeating steps in a loop

You can usually recognise them from their pseudocode forms:

• Assignment uses the arrow ←
• Selection uses IF...THEN...ENDIF or CASE OF
• Iteration uses loops such as WHILE...ENDWHILE or REPEAT...UNTIL

A single extract can contain more than one construct. For example, an IF statement may contain an assignment inside it.

Understanding the Question

You are given several short pseudocode extracts from Sales() and must tick whether each extract includes:

• assignment
• selection
• iteration

The question warns that each extract may contain one or more of these, so you must inspect each row carefully rather than assuming only one tick per line.

Approach

Look for the key feature in each extract:

• If you see ←, that is assignment.
• If you see IF or CASE, that is selection.
• If you see WHILE or REPEAT...UNTIL, that is iteration.

Then check whether the extract contains more than one of these features.

Step-by-Step Reasoning

1. Result ← CalculateTotal()

This stores the value returned by CalculateTotal() into Result.

• It contains ←, so it is assignment.
• There is no IF, CASE, WHILE, or REPEAT, so it is not selection or iteration.

2. WHILE IsClosed

A WHILE loop repeats while a condition remains true.

• This is iteration.
• Although a condition is present, WHILE is classified as a loop, not as a selection statement.

3. REPEAT ... UNTIL Sales[4] > Value

A REPEAT...UNTIL structure keeps repeating until the condition becomes true.

• This is iteration.
• The condition controls when the repetition stops, but the structure itself is still a loop, not an IF/CASE selection.

4. IF Sales[Current] <= 150 THEN / Discount ← TRUE / ENDIF

This row has two things happening:

• IF ... THEN means selection because the statement only runs when the condition is true.
• Inside the IF, Discount ← TRUE is assignment because a value is stored in a variable.

So this row needs two ticks.

5. CASE OF Option

CASE OF selects one branch from several possible alternatives.

• This is selection.
• It is not assignment or iteration.

Key Takeaways

• ← indicates assignment.
• IF and CASE OF are selection constructs.
• WHILE and REPEAT...UNTIL are iteration constructs.
• One extract can include more than one construct, so always check the whole row.

Common Mistakes

• Ticking selection for every statement with a condition. A loop condition in WHILE or UNTIL is still part of iteration.
• Missing the assignment inside an IF statement.
• Thinking a function call automatically makes something iteration or selection; it does not.
• Giving only one tick per row when the question allows more than one.

Things to Be Careful About

• In Cambridge pseudocode, assignment is shown by ←, not =.
• CASE OF is a selection structure even if the branches are not shown in the extract.
• REPEAT...UNTIL is a post-condition loop: it repeats first, then checks the condition.
• WHILE is a pre-condition loop: it checks the condition before each repetition.

Background Concept

Decomposition is a problem-solving technique used in program design. Instead of trying to solve one large, complicated problem all at once, the problem is split into smaller parts.

These smaller parts are often called:

• sub-problems
• modules
• components

Each module should have a clear purpose, such as entering stock data, calculating sales totals, or checking whether an item is in stock.

Decomposition is closely linked to modular design. A modular program is easier to understand, build, test, and maintain.

Understanding the Question

The question says decomposition has been used to design a stock-control program and asks you to describe decomposition.

So you are not being asked to give code. You are being asked for the idea behind the design method.

A strong answer should say:

• what decomposition is
• what the smaller parts are for
• why this helps when developing the whole program

Approach

Give a definition first, then expand it with what happens to the smaller parts.

A good structure is:

1. break the large problem into smaller modules
2. each module solves one task
3. modules can be worked on separately and then combined

That covers both meaning and purpose.

Step-by-Step Reasoning

The whole stock-control system is a large task. It may need to:

• store stock details
• record sales
• update stock levels
• check availability
• produce reports

Instead of writing one huge block of logic, decomposition separates this into modules. For example, one module might handle sales, another stock checking, and another report generation.

This means:

• each module is smaller and easier to understand
• programmers can focus on one task at a time
• modules can be tested individually
• the finished modules are joined together to make the complete system

So the essential description is that decomposition breaks a complex problem into manageable modules, each with its own specific job.

Key Takeaways

• Decomposition is breaking a problem into smaller parts.
• Each module should do one clear task.
• Modular design makes development and testing easier.
• It is a standard design technique in algorithm development.

Common Mistakes

• Describing abstraction instead of decomposition. Abstraction removes unnecessary detail; decomposition splits the problem.
• Saying only that it makes the program easier, without defining what decomposition actually is.
• Talking about writing code line by line rather than dividing the overall problem into modules.

Things to Be Careful About

• The question asks to describe decomposition, so include both the definition and how the smaller modules are used.
• Do not confuse modules with individual lines of code; a module is a meaningful section that performs a task.
• Keep the answer focused on design, not on specific programming syntax.

Background Concept

In program development, different kinds of errors happen at different stages:

• Syntax errors: the program breaks the grammar rules of the language
• Logic errors: the program runs but gives the wrong result
• Run-time errors: the program starts correctly but fails while executing

This question asks for two error types other than logic errors, so the expected choices are syntax error and run-time error.

Understanding the Question

The question says all the logic errors have been corrected. That means you must identify two different remaining categories of error the coded program could still contain.

You must do two things for each:

1. name the type of error
2. describe what it means

Approach

Use the two standard alternatives to logic error:

• syntax error
• run-time error

Then describe each clearly enough to show how it differs from the others.

Step-by-Step Reasoning

1. Syntax error

A syntax error means the programmer has written code that does not follow the rules of the programming language.

Examples include:

• a misspelt keyword
• missing brackets or punctuation
• a statement written in the wrong format

Because the structure of the code is invalid, the translator detects the problem before the program can run properly.

2. Run-time error

A run-time error happens after the program has started executing. The code may be syntactically correct, but something goes wrong during execution.

Typical causes include:

• invalid data
• division by zero
• trying to access something that does not exist

The effect is usually that the program stops, crashes, or produces an execution failure.

These are both different from logic errors, where the program continues running but produces the wrong output.

Key Takeaways

• Syntax errors are language-rule mistakes found before successful execution.
• Run-time errors happen during execution.
• Logic, syntax, and run-time errors are separate categories and should not be mixed up.

Common Mistakes

• Giving logic error as one of the two answers, even though the question says other types.
• Naming an error type but not describing it.
• Describing a logic error as if it were a run-time error.
• Saying a syntax error happens while the program is running.

Things to Be Careful About

• Make sure the two error types are distinct.
• Include both the name and the description for each one.
• Keep the descriptions general and accurate; they do not need to be tied to one exact line of this program.

Background Concept

There are three common loop types in Cambridge pseudocode:

• A count-controlled loop (FOR ... NEXT) is used when the number of repetitions is known before the loop begins.
• A pre-condition loop (WHILE ... ENDWHILE) is used when the loop may run an unknown number of times and the condition is tested before each iteration.
• A post-condition loop (REPEAT ... UNTIL) is used when the loop body must execute at least once.

The key question is: do we know in advance how many times the loop should repeat? If yes, FOR ... NEXT is usually the best choice.

Understanding the Question

The algorithm starts with I ← 2 and the outer loop continues while I <= 4. At the end of each pass, I ← I + 1.

So the outer loop will use these values of I:

• 2
• 3
• 4

That is a fixed number of iterations: exactly 3 passes. The question asks which loop structure is most appropriate, not just which loop currently works.

Approach

Look at the loop control variable:

• starting value: 2
• ending value: 4
• step size: +1

Because all three are known before the loop starts, the correct choice is a count-controlled loop.

Step-by-Step Reasoning

The given outer loop is:

• I ← 2
• WHILE I <= 4
• ...
• I ← I + 1
• ENDWHILE

This works, but it is not the most suitable structure.

Why?

Because the loop is behaving exactly like a count-controlled loop:

• it starts from a known value
• it ends at a known value
• it changes by a fixed amount each time

A WHILE loop is more suitable when the number of repeats is not known in advance, for example when reading until end-of-file or waiting until a condition becomes true.

Here, the outer loop always makes 3 passes, so FOR I ← 2 TO 4 would express that more clearly.

That is why the justified answer is:

• Loop structure: FOR ... NEXT
• Justification: the number of iterations is known before the loop starts.

Key Takeaways

• Use FOR ... NEXT when the number of repetitions is fixed in advance.
• Use WHILE when the loop may run an unknown number of times.
• Always justify the loop choice using the start value, end value and step size if they are given.

Common Mistakes

• Saying just "loop" instead of naming the specific type such as FOR ... NEXT.
• Saying REPEAT ... UNTIL just because the loop must run more than once. That is not the reason to choose it.
• Giving a vague justification like "it is easier" instead of stating that the number of iterations is known in advance.

Things to Be Careful About

• The question asks for the most appropriate loop, not whether the given WHILE loop works.
• A correct justification should refer to the values of I: it starts at 2, ends at 4, and increases by 1.
• In Paper 2, be precise with pseudocode terminology: count-controlled, pre-condition, and post-condition.

Background Concept

This algorithm is doing an insertion-style sort on the character array Chars.

The idea of insertion sorting is:

1. treat the left part of the array as already sorted
2. take the next item, called the Key
3. move larger items one place to the right
4. insert the Key into the correct gap

In this algorithm:

• I marks the position of the current item being inserted
• Key stores that item temporarily
• J moves left through the already sorted part of the array

Because the values are characters, comparisons such as Chars[J] > Key use alphabetical / character-code order.

Understanding the Question

You are given the full pseudocode and the starting array:

• Chars[1] = 'D'
• Chars[2] = 'T'
• Chars[3] = 'H'
• Chars[4] = 'R'

The task is to dry run the algorithm and fill in the trace table. That means you must follow the code line by line and record the values of:

• I
• Key
• J
• Chars[J]
• the four array positions

The important thing is not just the final sorted array. You must also show the intermediate values as the algorithm shifts elements and inserts the key.

Approach

The safest way to do this trace is by handling one outer-loop pass at a time.

For each value of I:

1. copy Chars[I] into Key
2. set J ← I - 1
3. test whether Chars[J] > Key
4. if true, shift Chars[J] right into Chars[J + 1]
5. decrease J
6. repeat until the correct position is found
7. place Key into Chars[J + 1]
8. increase I

This prevents losing track of what has moved and what has stayed the same.

Step-by-Step Reasoning

Start with:

• I = 2
• array = 'D', 'T', 'H', 'R'

That is the first row already given.

Pass 1: I = 2

• Key ← Chars[2] = 'T'
• J ← 1
• compare Chars[1] with Key: 'D' > 'T' is false
• so the inner loop does not run
• Chars[J + 1] ← Key means Chars[2] ← 'T', which changes nothing
• I ← 3

So after the first pass, the array is still:

• 'D', 'T', 'H', 'R'

Pass 2: I = 3

• Key ← Chars[3] = 'H'
• J ← 2
• compare Chars[2] with Key: 'T' > 'H' is true
• shift right: Chars[3] ← Chars[2], so position 3 becomes 'T'
• J ← 1
• compare Chars[1] with Key: 'D' > 'H' is false
• stop shifting
• insert key: Chars[J + 1] ← Key means Chars[2] ← 'H'
• I ← 4

Now the array becomes:

• 'D', 'H', 'T', 'R'

Pass 3: I = 4

• Key ← Chars[4] = 'R'
• J ← 3
• compare Chars[3] with Key: 'T' > 'R' is true
• shift right: Chars[4] ← Chars[3], so position 4 becomes 'T'
• J ← 2
• compare Chars[2] with Key: 'H' > 'R' is false
• stop shifting
• insert key: Chars[J + 1] ← Key means Chars[3] ← 'R'
• I ← 5

Now the array becomes:

• 'D', 'H', 'R', 'T'

Loop ends

The outer loop condition is I <= 4.

After the final increment, I = 5, so 5 <= 4 is false and the algorithm stops.

Final array:

• Chars[1] = 'D'
• Chars[2] = 'H'
• Chars[3] = 'R'
• Chars[4] = 'T'

That is why the completed trace table ends with I = 5 and the sorted array D H R T.

Key Takeaways

• Dry running means following each statement in order and updating variables carefully.
• In insertion sort, Key is stored temporarily while larger items are shifted right.
• The inner loop moves left through the sorted part of the array.
• The final position for Key is J + 1.

Common Mistakes

• Forgetting to store the current value in Key before shifting array elements.
• Moving J the wrong way; here J decreases because the algorithm checks leftwards.
• Forgetting that characters are compared alphabetically, so 'T' > 'H' is true but 'D' > 'H' is false.
• Writing the final sorted array correctly but missing intermediate trace rows, which loses marks.
• Putting Key back into Chars[J] instead of Chars[J + 1].

Things to Be Careful About

• Keep the order of statements exactly as written in the pseudocode.
• When an item is shifted, it is copied into Chars[J + 1], not swapped.
• The array is indexed from 1 to 4, so always track positions carefully.
• The condition uses Chars[J] > Key; do not compare the wrong array element after J changes.
• The trace table records state changes across the run, so missing a single shift can make all later rows wrong.

Background Concept

A validation module checks whether input data is sensible and allowed before the rest of the program uses it. A good test plan does not just try one typical value. It should include:

• normal data: a typical valid value inside the range
• boundary data: values at the edge of the allowed range, and often just next to that edge
• abnormal data: invalid values that should be rejected

Here the allowed values are integers from 0 to 60 inclusive. The word inclusive is important: it means both 0 and 60 are valid.

Understanding the Question

The question says the sensor speed value should be in the range 0 to 60 inclusive. It also tells you two extra facts:

• the sensor only produces integer values
• the sensor cannot read values less than 0

So you do not need to test decimals, and a negative value is not a realistic sensor output in this situation. One normal test has already been given: 36, which should be accepted. You need four more rows to fully test the validation.

Approach

Because a normal case is already provided, the best extra cases are the important edge cases:

• the lower limit itself: 0
• just above the lower limit: 1
• the upper limit itself: 60
• just above the upper limit: 61

Then decide whether each should be accepted or rejected based on the rule 0 to 60 inclusive.

Step-by-Step Reasoning

• 0 is the smallest allowed value, so it is valid and should be accepted.
• 1 is just inside the valid range, so it should also be accepted.
• 60 is the largest allowed value, so it is valid and should be accepted.
• 61 is just outside the valid range, so it should be rejected.

These tests are strong because they focus on where validation errors usually happen: right at the edges of the range.

Key Takeaways

• For range checking, always test the limits as well as a typical value.
• The word inclusive means the endpoints are valid.
• Boundary testing is often the most important part of a validation test plan.

Common Mistakes

• Using -1 as a test case even though the question says the sensors cannot read values less than 0.
• Using a decimal value even though the question says the sensor values are integers.
• Saying 60 is rejected. It is not rejected because the range is inclusive.
• Only giving normal data and missing the boundary cases.

Things to Be Careful About

• Read the range carefully: 0 to 60 inclusive means both ends are accepted.
• The type of test data must match the value chosen.
• The expected outcome should clearly say whether the data item is accepted or rejected.
• If a centre labels 61 as abnormal instead of boundary, that still reflects the same idea: it is outside the valid range. The essential point is that it must be rejected.

Background Concept

Bubble sort repeatedly compares adjacent items and swaps them if they are in the wrong order. After one full pass, the largest remaining item has "bubbled" to the end of the unsorted section.

An efficient bubble sort improves the basic version in two ways:

• it stops early if a whole pass makes no swaps, because the data is already sorted
• it reduces the range checked on later passes, because the last item in each pass is already in the correct place

In this question, each row of the 2D array is a record made from two linked pieces of data:

• column 1 = sensor value
• column 2 = sensor ID

That means when two readings are swapped, both columns of the row must move together. If you swap only the sensor values, the IDs would no longer match the correct readings.

Understanding the Question

You are given a global array:

Reading[1:2000, 1:2]

This means:

• there are 2000 rows
• there are 2 columns
• the array is 1-indexed, not 0-indexed

The procedure must sort the rows into ascending order of sensor value, so the comparison key is Reading[row, 1]. Because the question explicitly asks for an efficient bubble sort, a simple bubble sort without early stopping would not be the best answer.

Approach

Use this structure:

1. Set a variable such as Last to 2000 to show the end of the unsorted section.
2. Repeat passes through the array until no swaps are made.
3. On each pass, compare Reading[Row, 1] with Reading[Row + 1, 1].
4. If the first is bigger, swap the entire row data for those two positions.
5. Set Swapped to TRUE whenever a swap happens.
6. After the pass, reduce Last by 1 because the final item in that pass is now in the correct place.

This gives the correct sort order and also satisfies the requirement for efficiency.

Step-by-Step Reasoning

First, local variables are declared:

• Row controls the inner loop
• Last stores the last unsorted row
• TempValue and TempID temporarily hold one row's data during a swap
• Swapped records whether any exchange happened in the current pass

Last ← 2000

The whole array is initially unsorted, so the unsorted section runs to row 2000.

REPEAT

We need at least one pass through the data, so a REPEAT ... UNTIL structure fits well.

Swapped ← FALSE

At the start of each pass, assume no swaps will be needed. If any swap happens, change this to TRUE.

FOR Row ← 1 TO Last - 1

The loop stops at Last - 1 because each comparison uses both Row and Row + 1. If the loop went to Last, then Row + 1 would go out of bounds.

IF Reading[Row, 1] > Reading[Row + 1, 1] THEN

For ascending order, larger values must move right. So if the current row's sensor value is greater than the next row's sensor value, they are in the wrong order.

The swap:

• save the current row's value and ID in temporary variables
• copy the next row into the current row
• copy the saved value and ID into the next row

Notice that both columns are swapped, not just column 1.

Swapped ← TRUE

This records that the pass made a change, so another pass may still be needed.

After the loop finishes:

Last ← Last - 1

The largest item involved in that pass is now at the end of the unsorted section, so the next pass does not need to check it again.

UNTIL Swapped = FALSE OR Last = 1

If Swapped is still FALSE, then the pass made no exchanges and the array is sorted. Last = 1 is a safe stopping condition when only one item remains in the unsorted section.

Key Takeaways

• In a 2D array storing linked data, sort by the key column but swap the whole record.
• Efficient bubble sort uses a swap flag and a shrinking upper bound.
• For ascending order, swap when the left item is greater than the right item.
• With a 1-indexed array, loop bounds must be chosen carefully to avoid going past the end.

Common Mistakes

• Swapping only Reading[Row, 1] and forgetting Reading[Row, 2]. This breaks the connection between each sensor value and its sensor ID.
• Looping to 2000 or Last instead of Last - 1, which makes Reading[Row + 1, 1] go out of bounds.
• Forgetting to reset Swapped to FALSE at the start of each pass.
• Writing a basic bubble sort without any efficiency feature, even though the question asks for an efficient version.
• Using the comparison the wrong way round and producing descending instead of ascending order.

Things to Be Careful About

• The array starts at row 1, not row 0.
• Column 1 is the sensor value; column 2 is the sensor ID. Only column 1 is used for comparison, but both columns must be swapped.
• The condition for ascending order is > when comparing the left item with the right item.
• Every local variable should be declared in CIE pseudocode.
• Use the CIE assignment arrow ←, not = for assignment.

Background Concept

A module is a self-contained part of a program that performs one task. In this case, the module must both produce output and give back a new value for the customer's points total, so writing it as a FUNCTION is appropriate because a function can return a value.

This question also relies on selection and integer arithmetic:

• selection is needed because the rules are different for one coffee and for multiple coffees
• DIV gives the whole-number quotient, which is useful for counting how many free coffees can be claimed from a points total
• MOD gives the remainder left after whole groups have been removed, which is useful for finding the points left over after free coffees are awarded

For example, if a customer has 25 points after ordering, then:

• 25 DIV 11 = 2, so they earn 2 free coffees
• 25 MOD 11 = 3, so 3 points remain

Understanding the Question

The module CustomerOrder() is called whenever one customer places one order. It is given:

• the number of coffees ordered
• the current number of points

It must then:

1. add the ordered coffees to the points total
2. work out how many free coffees are earned
3. output a message showing that number
4. return the new points total after any deductions

The important wording is that the total number of points is increased first, and only then are the free-coffee rules applied. Another key detail is that there are two different cases:

• if exactly one coffee is ordered, at most one free coffee is awarded
• if multiple coffees are ordered, whole groups of 11 points can give several free coffees

Approach

A good structure is:

1. add NumberOfCoffees to Points
2. start FreeCoffees at 0
3. use an outer IF to test whether exactly one coffee was ordered
4. inside each branch, only award free coffees if the new total is greater than 10
5. output the result and return the updated points total

For the multiple-coffee case, DIV and MOD make the algorithm short and accurate:

• Points DIV 11 calculates how many free coffees to give
• Points MOD 11 calculates the remaining points afterwards

Step-by-Step Reasoning

First, the points must be updated:

Points ← Points + NumberOfCoffees

This matches the rule that every ordered coffee adds one point.

Next, initialise:

FreeCoffees ← 0

This is important because if no free coffees are earned, the program still needs a correct value to output.

Now handle the one-coffee case:

• if NumberOfCoffees = 1
• and the new Points > 10
• then exactly one coffee is free
• so set FreeCoffees ← 1
• and reduce points by 11

So that branch is:

• FreeCoffees ← 1
• Points ← Points - 11

Then handle the multiple-coffee case in the ELSE branch:

• if the new Points > 10
• then the number of free coffees is the number of whole 11-point groups
• so FreeCoffees ← Points DIV 11
• and the remaining points are Points MOD 11

Using the example in the question:

• current points = 9
• ordered coffees = 16
• new points = 25
• 25 DIV 11 = 2, so 2 free coffees
• 25 MOD 11 = 3, so 3 points remain

Finally, output the number of free coffees and return the updated points total.

Key Takeaways

• Add to the points total before checking reward conditions.
• Use nested IF statements when the business rules split into cases.
• Use DIV for the number of complete rewards and MOD for the leftover value.
• A function is suitable when a module must return a calculated value.

Common Mistakes

• Checking the reward condition before adding the newly ordered coffees to the points total.
• Forgetting to initialise FreeCoffees to 0, which can leave it undefined when no reward is earned.
• Using the multiple-coffee formula for the one-coffee case without following the rule given in the question.
• Subtracting 11 only once in the multiple-coffee case instead of once for every free coffee.
• Returning the number of free coffees instead of returning the new points total.

Things to Be Careful About

• The condition is Points > 10, not Points = 10.
• Use DIV and MOD, not real-number division.
• Keep the identifier names consistent with the question, such as CustomerOrder().
• In CIE pseudocode, use the assignment arrow ←, not =.
• Because the module must return the new points total, a FUNCTION is the clearest choice here.