Mark Scheme
Section A — Structured Questions (45 marks)
QUESTION 1
(a) [1 mark]
- 1500 // Accept: 1500 elements
(b) [2 marks]
Award 1 mark each for two of:
- A boolean can only have two values (TRUE/FALSE) // Accept: two states
- This matches the two states a book can be in (available or not available)
- Uses less storage space than other data types // Accept: efficient storage
- Simplifies checking the status
(c) [3 marks]
- Line 1:
TRUE
- Line 2:
Counter + 1 // Accept: increment Counter
- Line 3:
BookFound = TRUE OR Counter > 500 // Accept: equivalent conditions such as Counter = 501
Award 1 mark per correct line.
(d) [4 marks]
Award 1 mark per advantage, up to 2 advantages. Award 1 additional mark per advantage for development/explanation.
Possible answers include:
- Data persists when the program closes [1] so loan records are not lost between sessions [1]
- Files can store more data than arrays [1] as they are not limited by available RAM [1]
- File data can be backed up easily [1] providing security against data loss [1]
- Multiple programs can access the same file [1] allowing data sharing across the system [1]
- Files can grow dynamically [1] without needing to specify a fixed size in advance [1]
QUESTION 2
(a) [1 mark]
- There is no count-controlled loop in this code // Accept: None / No count-controlled loop present
- The loop shown is condition-controlled
(b) [1 mark]
(c) [2 marks]
Award 1 mark for identifying it controls loop termination.
Award 1 mark for explaining it tracks whether the correct guess has been made.
Example answer:
- It acts as a flag/control variable to determine when to stop the loop [1]
- It is set to TRUE when the player guesses correctly [1]
(d) [5 marks]
Award marks for:
- Appropriate loop structure [1]
- Input prompt [1]
- Validation condition checking range [1]
- Appropriate error message [1]
- Correct loop termination [1]
Example answer:
REPEAT
OUTPUT "Enter your guess (1-100): "
INPUT PlayerGuess
IF PlayerGuess < 1 OR PlayerGuess > 100
THEN
OUTPUT "Invalid input. Please enter a number between 1 and 100."
ENDIF
UNTIL PlayerGuess >= 1 AND PlayerGuess <= 100
Accept equivalent solutions including WHILE loops or flag variables.
QUESTION 3
(a) [4 marks]
- Line 1:
AdultTickets + ChildTickets
- Line 2:
8.0 // Accept: 8
- Line 3:
0.9 // Accept: 0.90
- Line 4:
TotalCost
Award 1 mark per correct answer.
(b) [1 mark]
- 36.0 // Accept: 36 / $36.00
- Working: (2 × 12) + (3 × 8) = 24 + 24 = 48, then 48 × 0.9 = 43.2
Correction to mark scheme: The correct answer should be 43.2
- Working: (2 × 12) + (3 × 8) = 24 + 24 = 48, total tickets = 5 (≥4), so 48 × 0.9 = 43.2
(c) [2 marks]
Award 1 mark for identifying an advantage.
Award 1 mark for explanation/development.
Possible answers:
- Code reusability [1] – the function can be called multiple times without rewriting code [1]
- Easier maintenance [1] – changes only need to be made in one place [1]
- Makes code more readable [1] – the function name describes what it does [1]
- Easier testing [1] – the function can be tested independently [1]
QUESTION 4
(a) [2 marks]
Award 2 marks for fully correct answer.
Award 1 mark if smallest value (12) is in first position but other swaps incorrect.
Working:
- Compare 34,12 → swap → 12,34,56,23,78
- Compare 34,56 → no swap → 12,34,56,23,78
- Compare 56,23 → swap → 12,34,23,56,78
- Compare 56,78 → no swap → 12,34,23,56,78
(b) [1 mark]
- 4 // Accept: four comparisons
(c) [3 marks]
Award 1 mark for each correct comparison point, maximum 3 marks.
Possible answers:
- Bubble sort still makes all comparisons even if list is sorted [1] – O(n²) in best case [1]
- Insertion sort is efficient with sorted data [1] – O(n) in best case [1]
- Insertion sort would be better for nearly sorted data [1]
- Bubble sort would perform unnecessary swaps/passes [1]
- Insertion sort recognizes the list is sorted and terminates early [1]
QUESTION 5
(a) [1 mark]
(b) [3 marks]
SELECT FirstName, LastName
FROM STUDENTS
WHERE YearGroup = 10
Award marks:
- SELECT FirstName, LastName [1]
- FROM STUDENTS [1]
- WHERE YearGroup = 10 [1]
Accept minor syntax variations (e.g., case differences).
Reject if essential keywords missing or incorrect table/field names used.
(c) [2 marks]
SELECT AVG(HousePoints)
FROM STUDENTS
Award marks:
- AVG(HousePoints) [1]
- FROM STUDENTS [1]
Accept: SELECT AVG(HousePoints) FROM STUDENTS;
(d) [3 marks]
Award 1 mark for identifying many-to-many relationship issue.
Award 1 mark for explaining students can be in multiple classes.
Award 1 mark for explaining data redundancy/update anomaly problem.
Example answer:
- A student can enrol in multiple classes [1]
- Each class can have multiple students [1]
- This creates a many-to-many relationship which requires a linking table to avoid data redundancy [1]
Accept: answers that discuss update anomalies, data duplication, or normalization.
QUESTION 6
(a) [2 marks]
Award 1 mark each for two of:
- Length check (minimum 8 characters) // Accept: length validation
- Presence check for at least one digit // Accept: contains a number
- Character-by-character examination
(b) [2 marks]
Award marks for:
- Extracts a substring/character [1]
- From a specified position in the string [1]
Accept: "Returns one character from the password at the position specified by Counter"
(c) [2 marks]
- Password rejected [1]
- Because although it has 8 characters (meets length requirement), it contains no digits [1]
Accept equivalent explanations that identify both conditions.
(d) [1 mark]
Award 1 mark for any sensible additional check:
- Check for at least one uppercase letter
- Check for at least one special character
- Check for at least one lowercase letter
- Check against common password list
- Maximum length check
Section B — Extended Response (30 marks)
QUESTION 7
(a) [12 marks]
Level 3 (9-12 marks):
Comprehensive discussion that evaluates both options with specific reference to the delivery route planning context. Shows clear understanding of the characteristics of both language types. Makes a justified recommendation. Covers at least 4 of the 5 given considerations with good technical depth. Uses accurate technical terminology throughout.
Level 2 (5-8 marks):
Sound discussion covering several points. Makes comparisons between high-level and low-level languages. Addresses at least 3 considerations with some development. May be more descriptive than evaluative. Some technical terminology used correctly. Limited reference to the specific context.
Level 1 (1-4 marks):
Basic description of differences between language types. Limited development. May focus on only one or two considerations. May contain inaccuracies. Weak or no contextual reference. Limited technical terminology.
0 marks: No creditable content.
Indicative content:
Ease of development and maintenance:
- High-level languages are closer to human language / use English-like commands
- Easier to write, understand, and debug
- Low-level languages require detailed knowledge of hardware architecture
- High-level languages have extensive libraries for file handling, calculations
- Much faster development time with high-level languages
- Easier to train new programmers / lower skill requirements
Execution speed:
- Low-level languages execute faster / more efficient
- Direct hardware control possible
- However, for this application, calculation speed is unlikely to be critical
- Modern high-level languages are sufficiently fast for route planning
- Compiler optimizations reduce the performance gap
Hardware control:
- Low-level languages provide precise control of CPU and memory
- Not necessary for this application (no real-time requirements)
- High-level languages provide adequate control through libraries
- Operating system handles hardware abstraction
Portability:
- High-level languages are platform-independent / portable
- Can run on different operating systems with little or no modification
- Low-level languages are hardware-specific
- Important as delivery company may use different computer systems
- Code can be deployed to drivers' mobile devices if high-level
Cost of development:
- High-level language development is much cheaper
- Shorter development time reduces costs
- Easier to maintain and update
- Low-level languages require specialist programmers (higher salaries)
- Training costs lower for high-level languages
Conclusion should indicate high-level language is clearly more suitable for this application.
(b) [8 marks]
Award marks according to the following scheme:
- Declares variable for counting [1]
- Opens file correctly [1]
- Loop structure to read through file [1]
- Reads data from file correctly [1]
- Checks status field correctly [1]
- Increments counter when condition met [1]
- Outputs result [1]
- Closes file [1]
Award max 7 marks if no error handling present.
Example answer:
PendingCount ← 0
OPENFILE "Deliveries.txt" FOR READ
IF FILEOPEN = TRUE THEN
WHILE NOT EOF("Deliveries.txt")
DeliveryRecord ← READFILE "Deliveries.txt"
// Split record into fields
Fields ← SPLIT(DeliveryRecord, ",")
Status ← Fields[3]
IF Status = "Pending" THEN
PendingCount ← PendingCount + 1
ENDIF
ENDWHILE
CLOSEFILE "Deliveries.txt"
OUTPUT "Total pending deliveries: ", PendingCount
ELSE
OUTPUT "Error: Could not open file"
ENDIF
Accept variations in:
- Method of reading file (line by line, all at once)
- Method of extracting status field
- Exact error handling implementation
- Loop type (REPEAT UNTIL EOF, FOR loop if length known)
(c) [2 marks]
Award 1 mark for each valid reason, maximum 2:
- Frees up system resources / releases memory [1]
- Prevents file corruption [1]
- Allows other programs to access the file [1]
- Ensures all data is written/flushed to disk [1]
- Prevents data loss [1]
QUESTION 8
(a) [4 marks]
| Iteration |
Lower |
Upper |
Middle |
Comparison |
| 1 |
1 |
9 |
5 |
35 < 58 |
| 2 |
1 |
4 |
2 |
35 > 24 |
| 3 |
3 |
4 |
3 |
35 = 35 ✓ |
Award marks:
- Correct values for iteration 1 [1]
- Correct values for iteration 2 [1]
- Correct values for iteration 3 [1]
- Correct identification that value is found [1]
Accept alternative formats (not necessarily a table) if values are clearly shown.
Accept if Middle calculation is shown (e.g., (1+9) DIV 2 = 5).
(b) [6 marks]
Level 2 (4-6 marks):
Clear evaluation comparing both algorithms. Correctly identifies Big O notation for both. Explains preconditions clearly. Discusses appropriate situations for each algorithm with justification. Good use of technical terminology.
Level 1 (1-3 marks):
Basic comparison attempted. May identify efficiency differences but without Big O notation or with errors. Limited discussion of preconditions or appropriate situations. Some technical terminology used.
0 marks: No creditable content.
Indicative content:
Efficiency comparison:
- Binary search: O(log n) time complexity
- Linear search: O(n) time complexity
- Binary search is much faster for large datasets
- Example: for 1000 items, linear search averages 500 comparisons, binary search maximum 10
- Performance difference increases as dataset grows
- Binary search divides search space in half each iteration
Preconditions for binary search:
- Data must be sorted (in ascending or descending order)
- Must have direct access to middle element (array/list structure)
- If data is unsorted, must sort first (which has time cost)
- Must be able to calculate middle position
Situations where linear search might be more appropriate:
- Very small datasets (overhead not worth it)
- Unsorted data where sorting cost exceeds search savings
- When data is frequently updated (maintaining sorted order is expensive)
- Searching linked lists (no direct access to middle element)
- When searching for multiple occurrences / all matches
- When the item is likely to be near the start of the list
Application to product search system:
- For large product catalogues, binary search is clearly better
- Products can be sorted by ProductID when database is created
- Sorting cost is one-time / infrequent
- Fast search response improves user experience
- However, if searching by product name or price, data must be re-sorted or use linear search
Sample Answers with Examiner Commentary
Question 7(a) — Sample Answers
Grade A (high distinction) answer*
For the delivery route planning system, a high-level programming language such as Python would be far more suitable than a low-level language like assembly.
In terms of ease of development and maintenance, high-level languages provide a clear advantage. Python has English-like syntax such as "IF", "WHILE", and "OPEN FILE" which makes the code easier to write and understand. The system needs to handle complex tasks like reading addresses from files and calculating routes, and Python has extensive built-in libraries for file operations (like open(), read(), close()) and data structures (lists, dictionaries) that make these tasks straightforward. In contrast, assembly language requires the programmer to manage memory allocation manually and write lengthy code for simple operations. If the company needs to update the system (for example, to add new features like estimated delivery times), this would be much easier with Python where changes can be made quickly. Assembly code would need extensive rewriting and would require specialist programmers who understand the specific processor architecture, making maintenance very expensive.
Regarding execution speed, low-level languages do execute faster because they translate directly to machine code with minimal overhead. However, for this application, execution speed is not the critical factor. The system is planning routes, not controlling real-time machinery or processing data in microseconds. The route calculations might take a few seconds with Python, which is perfectly acceptable for planning daily deliveries. Modern high-level languages are optimized and fast enough for this business application. The time saved in development far outweighs any minor execution speed benefits.
Hardware control is not needed for this system. The delivery planning application does not need to interact directly with CPU registers or control specific memory addresses. It needs to perform standard operations like reading files, processing text, and outputting results, all of which are handled excellently by high-level languages through operating system interfaces. Assembly language's ability to control hardware precisely is simply unnecessary here.
Portability is a major advantage for the high-level option. The delivery company likely uses a variety of computer systems in different offices and drivers may use tablets or smartphones. Python code can run on Windows, macOS, Linux, and mobile platforms with little or no modification. Assembly language is processor-specific – code written for Intel processors would not work on ARM processors used in mobile devices. This lack of portability would force the company to rewrite the entire system for each platform, multiplying costs enormously.
Finally, considering cost of development, high-level languages are significantly cheaper. Python programmers are more readily available and command lower salaries than assembly language specialists. Development time would be measured in weeks rather than months or years. Training existing staff to maintain the system would be straightforward with Python but extremely difficult with assembly. The ongoing maintenance costs would be much lower.
In conclusion, a high-level programming language like Python is clearly the appropriate choice for this delivery route planning system. While low-level languages offer execution speed and hardware control, these benefits are irrelevant for this application and are vastly outweighed by the advantages of easier development, better portability, and much lower costs.
Mark: 12/12
Examiner commentary: This is an exemplary response that demonstrates comprehensive understanding of both language types with sustained evaluation throughout. The candidate addresses all five considerations in detail with specific reference to the delivery planning context. Excellent use of technical terminology (memory allocation, processor architecture, registers, portability). The answer shows clear judgment by explaining not just the differences but why they matter in this context (e.g., "execution speed is not the critical factor" with justification). The conclusion synthesizes the discussion effectively. This meets all Level 3 descriptors and achieves full marks.
Grade C (pass) answer
High-level languages are better for the delivery company system.
High-level languages are easier to program because they use normal words like IF and WHILE instead of complicated codes. This means the programmers can write the system faster and it won't take as long to make. Also if there is a bug it will be easier to find and fix. Low-level languages are very hard to understand and only expert programmers can use them.
Low-level languages are faster at running programs because they are closer to the computer. But for a delivery system this doesn't really matter because it doesn't need to be super fast. High-level languages are fast enough for this job.
High-level languages can work on different computers. The code can run on Windows or Apple computers. Low-level languages only work on one type of computer so you would have to write it again for different computers which would cost more money.
High-level languages cost less to make. It is quicker to write the code and there are more programmers who know high-level languages so they don't cost as much to employ. Low-level programmers are rare and expensive.
High-level languages also have things called libraries which have ready-made code for common tasks like opening files. This makes programming faster.
Therefore high-level languages are the best choice for the delivery company.
Mark: 7/12
Examiner commentary: This is a solid mid-level response that demonstrates reasonable understanding. The candidate correctly identifies that high-level languages are more suitable and provides several valid points: ease of programming, portability, cost, and libraries. However, the development lacks depth – for example, the portability section doesn't mention specific platforms relevant to a delivery company (mobile devices for drivers) and doesn't explain the technical reason why low-level languages are platform-specific. The discussion of execution speed is present but superficial. Only four of the five considerations are addressed (hardware control is missing). Technical terminology is limited and sometimes imprecise ("normal words", "closer to the computer"). The answer is more descriptive than evaluative in places. This places the response in the middle of Level 2.
Grade E (near miss) answer
High-level languages should be used because they are easier.
High-level languages like Python are easier to learn and use. They have simple commands and you don't need to know about the computer hardware. Low-level languages are difficult and need lots of training.
High-level languages are also portable. This means they can work on any computer. Low-level languages are not portable.
Another reason is that high-level languages are cheaper because it takes less time to write programs. Low-level languages take a long time.
High-level languages also run slower than low-level languages because they need to be translated. But this is okay for most programs.
So the delivery company should use high-level languages because they are easier and cheaper.
Mark: 3/12
Examiner commentary: This response demonstrates basic understanding but lacks the development and depth required for higher marks. The candidate makes several valid points (easier to use, portable, cheaper, execution speed) but provides minimal explanation or context. There is no specific reference to the delivery planning system's requirements. The statement "high-level languages run slower" is correctly identified but presented as a weakness without explaining why it doesn't matter in this context. Technical terminology is very limited ("translated" is mentioned but not explained). Only three considerations are addressed with any substance. The conclusion simply restates the opening without synthesizing the argument. The answer shows the candidate has some relevant knowledge but cannot develop or evaluate it effectively, which is typical of a Grade E response.
Question 7(b) — Sample Answers
Grade A (high distinction) answer*
PendingCount ← 0
FileOpened ← FALSE
TRY
OPENFILE "Deliveries.txt" FOR READ
FileOpened ← TRUE
WHILE NOT EOF("Deliveries.txt")
DeliveryLine ← READFILE "Deliveries.txt"
// Extract the status field (third field)
Fields ← SPLIT(DeliveryLine, ",")
Status ← Fields[2] // Index 2 for third field
IF Status = "Pending" THEN
PendingCount ← PendingCount + 1
ENDIF
ENDWHILE
CLOSEFILE "Deliveries.txt"
OUTPUT "Total pending deliveries: ", PendingCount
EXCEPT
IF FileOpened = TRUE THEN
CLOSEFILE "Deliveries.txt"
ENDIF
OUTPUT "Error: Unable to process file"
ENDTRY
Mark: 8/8
Examiner commentary: This is an exemplary pseudocode solution that demonstrates all required elements. The candidate correctly declares a counting variable, implements proper file opening with error handling using TRY-EXCEPT (or equivalent IF structure would be acceptable), uses an appropriate loop structure (WHILE NOT EOF), correctly reads and parses the file data, identifies and checks the status field, increments the counter appropriately, outputs the result, and closes the file. The error handling is sophisticated, ensuring the file is closed even if an error occurs. The comments enhance clarity. All 8 marking points achieved plus implicit error handling integrated throughout. This shows excellent programming logic and understanding of file operations.
Grade C (pass) answer
PendingCount ← 0
OPENFILE "Deliveries.txt" FOR READ
WHILE NOT EOF("Deliveries.txt")
Record ← READFILE "Deliveries.txt"
// Check if the record contains "Pending"
IF Record CONTAINS "Pending" THEN
PendingCount ← PendingCount + 1
ENDIF
ENDWHILE
CLOSEFILE "Deliveries.txt"
OUTPUT "Number of pending deliveries is: ", PendingCount
Mark: 5/8
Examiner commentary: This response demonstrates reasonable programming logic and captures the basic algorithm structure. The candidate correctly declares a counter (1 mark), opens the file (1 mark), implements a loop structure (1 mark), reads from the file (1 mark), and closes the file (1 mark), and outputs the result (awarded within the 5). However, there are significant weaknesses: no error handling for file operations (loses 1 mark), and the status checking is imprecise – using "CONTAINS" rather than properly extracting the third field means the algorithm would incorrectly count records where "Pending" appears in other fields like the address (loses proper field extraction mark). While the overall logic is sound, these technical shortcomings prevent full marks. This is typical of a Grade C response: correct overall approach but lacking sophistication and precision in implementation.
Grade E (near miss) answer
Count ← 0
OPEN "Deliveries.txt"
REPEAT
LINE ← READ FILE
IF LINE = "Pending" THEN
Count ← Count + 1
ENDIF
UNTIL END OF FILE
CLOSE FILE
OUTPUT Count
Mark: 2/8
Examiner commentary: This response shows basic awareness of the algorithm structure but contains multiple significant errors. The candidate does declare a variable (1 mark) and attempts to open and close the file (syntax is imprecise but intent is clear, 1 mark). However, critical problems include: incorrect loop syntax ("END OF FILE" is not properly checked), the file reading doesn't capture the line correctly (syntax is incomplete), the status check compares the entire line to "Pending" rather than extracting the status field (shows fundamental misunderstanding of file structure), no error handling, and the output doesn't include descriptive text. The algorithm would not function correctly as written. This demonstrates a student who understands that file operations and counting are required but cannot implement them accurately, which is characteristic of Grade E – showing partial knowledge but unable to construct a working solution.
Question 8(b) — Sample Answers
Grade A (high distinction) answer*
Binary search is significantly more efficient than linear search for the product search system, but this advantage depends on important preconditions being met.
In terms of algorithmic efficiency, binary search has a time complexity of O(log₂ n) while linear search has O(n). This means that binary search's performance increases logarithmically as the dataset grows, whereas linear search increases linearly. For example, with 1000 products, a linear search would need to check an average of 500 items (or all 1000 in the worst case where the item is last or not found), but binary search would need a maximum of only 10 comparisons (since log₂ 1000 ≈ 10). For an online shopping system with potentially thousands or tens of thousands of products, this difference is substantial – binary search would provide much faster response times, improving the customer experience significantly. As the product catalogue grows, binary search becomes increasingly advantageous; with 1 million products, linear search averages 500,000 comparisons but binary search needs only 20.
However, binary search has a critical precondition: the array must be sorted. In this system, the products are sorted by ProductID in ascending order, which means binary search can be used efficiently when searching by ProductID. This precondition also requires that the data structure allows direct access to any element (such as an array), because the algorithm needs to jump to the middle element. If the data were stored in a linked list, binary search would not be efficient because finding the middle element would require traversing the list.
There are situations where linear search might be more appropriate, despite being less efficient. First, if customers want to search by product name or price rather than ProductID, the array would need to be re-sorted by that field first, or a linear search would have to be used on the unsorted-by-that-field data. The cost of sorting (O(n log n) for efficient sorts) might exceed the benefit for a single search. Second, if the product database is frequently updated with new products being added, maintaining the sorted order adds overhead – every insertion requires finding the correct position and potentially shifting elements. In systems with very frequent updates, this maintenance cost might make linear search more practical. Third, for very small product catalogues (say, fewer than 20 items), the performance difference is negligible and the simpler linear search might be preferred.
For this online shopping system with products sorted by ProductID and likely containing hundreds or thousands of products, binary search is clearly the superior choice when searching by ProductID, offering dramatic performance improvements that directly benefit the user experience.
Mark: 6/6
Examiner commentary: This is an outstanding evaluation that demonstrates sophisticated understanding of algorithmic complexity. The candidate correctly identifies and explains Big O notation for both algorithms (O(log n) vs O(n)), provides concrete numerical examples that illustrate the practical significance of the difference, and shows understanding of how the efficiency gap widens with scale. The preconditions are explained clearly and completely: sorted data and direct access requirement. The discussion of situations where linear search might be appropriate is nuanced and contextual, mentioning alternative search fields, update frequency, and dataset size. The answer consistently relates the technical discussion back to the specific product search system context. This meets all Level 2 descriptors comprehensively and demonstrates A* grade analytical skills.
Grade C (pass) answer
Binary search is more efficient than linear search because it is faster.
Binary search has O(log n) efficiency and linear search has O(n) efficiency. This means binary search is better for big lists. For example if there are 100 items, linear search might have to check all 100 but binary search only checks about 7 times because it divides the list in half each time.
Binary search needs the list to be in order. The products are sorted by ProductID so binary search can work. If the list was not sorted then binary search would not find the right answer. Also binary search needs to be able to access the middle element quickly which works with arrays.
Linear search might be better in some situations. If the list is very small then it doesn't matter which search you use because both will be quick. Also if the list is not sorted then you have to use linear search or sort it first. If you are searching for something that is not the ProductID like the product name then the list might not be in the right order.
Overall binary search is more efficient for this system because the products are sorted and there are probably lots of products so the speed difference matters.
Mark: 4/6
Examiner commentary: This is a solid mid-level response that covers the main points but lacks the depth and precision of a top answer. The candidate correctly identifies Big O notation for both algorithms (though doesn't explicitly write O(log₂ n)) and attempts to illustrate the difference with an example. The preconditions are mentioned (sorted data, direct access) but not fully developed – for instance, there's no explanation of why the middle element must be quickly accessible or what data structures prevent this. The situations where linear search is appropriate are identified (small datasets, unsorted data, searching by different fields) but the explanations are brief and lack technical depth. The answer would benefit from more specific examples and clearer explanation of concepts like "divides the list in half." This demonstrates competent understanding but not the analytical sophistication required for top marks, placing it in Level 2 but at the lower end.
Grade E (near miss) answer
Binary search is faster than linear search.
Linear search looks at every item one by one until it finds the right one. This is slow. Binary search is faster because it splits the list and only looks at half.
Binary search only works if the list is sorted. If it is not sorted it won't work. The products are sorted so binary search can be used.
Linear search is easier to program. You just go through each item and check if it matches. Binary search is more complicated.
Binary search is better for this system because it is faster and the products are sorted so it will work.
Mark: 2/6
Examiner commentary: This response demonstrates basic awareness of the key concepts but lacks the technical detail and analytical depth required for higher marks. The candidate identifies that binary search is faster and requires sorted data, which shows fundamental understanding. However, there is no mention of Big O notation or any quantification of the efficiency difference – the claim that binary search is "faster" is unsupported by technical explanation. The description of how binary search works ("splits the list and only looks at half") is oversimplified and imprecise. The preconditions are incompletely stated – sorted data is mentioned but direct access requirement is not. The situations where linear search might be appropriate are not meaningfully discussed; "easier to program" is not a relevant efficiency consideration in this context. The answer lacks structure and technical vocabulary. This is characteristic of Grade E: the student has partial knowledge but cannot express or develop it with the precision and depth required for higher grades.