Select and use appropriate data types for a problem solution

10.1 Data Types and Records

Learning Objective

Students will be able to select the most appropriate primitive or derived data type for a given problem, define a record in Cambridge‑style pseudocode, and produce a complete identifier table. The content also covers the required array and file concepts and introduces the basic abstract data types (ADTs) that appear later in the syllabus.

Why Data Types Matter

  • Memory efficiency – each type occupies a defined amount of storage.
  • Correct calculations – integer division vs. real‑valued division, rounding, precision.
  • Run‑time safety – prevents overflow, under‑flow and type‑mismatch errors.
  • Readability & maintainability – a clear type tells the programmer what the data represents.

Primitive Data Types (Cambridge Specification)

Type Typical Size (bits) Range / Values Typical Use
INTEGER 32 ‑231 to 231‑1 Whole numbers, counters, indexes
REAL 32 (single) or 64 (double) ≈ ±3.4 × 1038 (≈7 dp) or ±1.8 × 10308 (≈15 dp) Measurements, scientific calculations, monetary values (when fixed‑point is not required)
CHAR 8 ASCII characters 0…127 Single characters, codes
STRING Variable (1 byte per character) Sequence of CHAR values; length fixed in the declaration Names, messages, textual data
BOOLEAN 1 (conceptually) TRUE / FALSE Logical conditions, flags
DATE Variable (often three INTEGER fields) Valid calendar dates, e.g. 2025‑12‑30 Birth dates, timestamps, scheduling

Derived Data Types (Cambridge Specification)

  • ARRAY – ordered collection of elements of the same primitive (or record) type.
  • RECORD – grouping of fields that may be of different primitive types; models a real‑world entity.
  • FILE – sequential collection of records stored on secondary storage; accessed with OPEN, READ, WRITE, CLOSE.

Assessment Objective (AO) Mapping

AO What is assessed How the notes address it
AO1 Recall terminology and definitions Lists of primitive/derived types, syntax for RECORD, ARRAY and FILE
AO2 Select appropriate data types and justify choices Decision checklist, examples with justification, AO‑mapping table
AO3 Design and use records, arrays and files in a program Full record definitions, identifier tables, array declaration, file‑handling snippets, bubble‑sort/linear‑search examples

Designing a Record – Step‑by‑Step

  1. Identify the real‑world entity to be modelled.
  2. List every attribute (field) that must be stored.
  3. Choose the most suitable primitive type for each attribute, considering range, precision and any special constraints (e.g., maximum string length).
  4. Write the record definition in Cambridge‑style pseudocode.
  5. Provide an identifier table that documents each field.

Example 1 – Student Record

Record Definition (Cambridge pseudocode)

record Student
    INTEGER studentID
    STRING  firstName[30]
    STRING  lastName[30]
    DATE    dateOfBirth
    REAL    gpa
    BOOLEAN isFullTime
endrecord

Identifier Table

Identifier Type Description
studentIDINTEGERUnique numeric identifier for the student
firstNameSTRING[30]Given name (max 30 characters)
lastNameSTRING[30]Family name (max 30 characters)
dateOfBirthDATEBirth date in the format YYYY‑MM‑DD
gpaREALGrade Point Average (0.0 – 4.0)
isFullTimeBOOLEANTRUE if the student is enrolled full‑time

Using the Record (pseudocode)

DECLARE stud : Student
stud.studentID   ← 10234
stud.firstName   ← "Emma"
stud.gpa         ← 3.75
IF stud.isFullTime THEN
    // process full‑time student
ENDIF

Example 2 – Library Book Management System (including ARRAY and FILE)

Record Definition

record Book
    STRING  ISBN[13]          // keep leading zeros
    STRING  title[100]
    STRING  author[50]
    INTEGER publishedYear
    REAL    price
    BOOLEAN isAvailable
endrecord

Identifier Table for Book

Identifier Type Description
ISBNSTRING[13]13‑digit International Standard Book Number
titleSTRING[100]Title of the book
authorSTRING[50]Author’s name
publishedYearINTEGERYear the book was published
priceREALRetail price (e.g. £12.99)
isAvailableBOOLEANTRUE if the book is on the shelf

Array of Records – Declaration

DECLARE library : ARRAY[1..1000] OF Book   // up to 1000 books
DECLARE numberOfBooks : INTEGER ← 0

Identifier Table for the Array

Identifier Type Description
libraryARRAY[1..1000] OF BookStores the collection of books in the library
numberOfBooksINTEGERCurrent count of valid entries in library

File Handling – Saving the Library (Sequential Access)

OPEN "library.dat" FOR WRITE AS bookFile
FOR i ← 1 TO numberOfBooks DO
    WRITE bookFile FROM library[i]
ENDFOR
CLOSE bookFile

File Handling – Loading the Library (Sequential Access)

OPEN "library.dat" FOR READ AS bookFile
i ← 1
WHILE NOT EOF(bookFile) DO
    READ bookFile INTO library[i]
    i ← i + 1
ENDWHILE
numberOfBooks ← i - 1
CLOSE bookFile

Selecting Data Types – Decision Checklist

  • Is the value whole or fractional? → INTEGER or REAL.
  • Will the value ever exceed the INTEGER range? → Use a larger type (e.g., LONG) or split the data.
  • Is the data textual? → CHAR for a single character, STRING[n] for longer text.
  • Does the value represent a calendar date? → DATE.
  • Do you need a binary condition? → BOOLEAN.
  • Are several related values required? → Define a RECORD and, if many instances are needed, an ARRAY of that record.
  • Will the data be stored permanently? → Use a FILE of the appropriate RECORD type.
  • Is numerical precision critical (e.g., money)? → Prefer REAL with explicit rounding or a fixed‑point representation.

Common Pitfalls

  • Overflow – using INTEGER for values > 2,147,483,647.
  • Leading zeros lost – storing identifiers such as ZIP codes or ISBNs as INTEGER; use STRING instead.
  • Unit mismatch – mixing metres and kilometres without conversion.
  • Uninitialised fields – can cause undefined behaviour; always assign a default value.
  • Incorrect file mode – opening a file for WRITE when you intend to READ will erase existing data.
  • Array out‑of‑bounds – accessing an index < 1 or > upper bound causes run‑time errors.

Summary

Effective problem solving begins with a careful analysis of the data involved. By matching each piece of information to the most appropriate primitive or derived type, documenting the choice in an identifier table, and grouping related items into a well‑defined RECORD (with optional ARRAY and FILE handling), students produce programs that are clear, efficient, and fully aligned with the Cambridge AS & A‑Level Computer Science 9618 syllabus.


10.2 Arrays

Array Fundamentals (Cambridge Specification)

  • Index base: Cambridge uses a lower bound of 1 unless otherwise stated.
  • Bounds: declared as ARRAY[lower..upper] OF <type>. The number of elements is upper – lower + 1.
  • Out‑of‑range errors occur if an index is less than the lower bound or greater than the upper bound.
  • Arrays may hold INTEGER, REAL, CHAR, STRING, BOOLEAN, DATE or any RECORD.

Iterating Over an Array (pseudocode)

DECLARE scores : ARRAY[1..10] OF INTEGER
FOR i ← 1 TO 10 DO
    scores[i] ← 0          // initialise each element
ENDFOR

Bubble‑Sort Example (INTEGER array)

PROCEDURE bubbleSort(arr : ARRAY[1..n] OF INTEGER, n : INTEGER)
    DECLARE i, j, temp : INTEGER
    FOR i ← 1 TO n-1 DO
        FOR j ← 1 TO n-i DO
            IF arr[j] > arr[j+1] THEN
                temp      ← arr[j]
                arr[j]    ← arr[j+1]
                arr[j+1]  ← temp
            ENDIF
        ENDFOR
    ENDFOR
ENDPROCEDURE

Linear‑Search Example (INTEGER array)

FUNCTION linearSearch(arr : ARRAY[1..n] OF INTEGER, n : INTEGER, key : INTEGER) RETURNS INTEGER
    DECLARE i : INTEGER
    FOR i ← 1 TO n DO
        IF arr[i] = key THEN
            RETURN i          // position of the key
        ENDIF
    ENDFOR
    RETURN 0                  // 0 indicates “not found”
ENDFUNCTION

Array of Records – Identifier Table (re‑using the Book record)

Identifier Type Description
libraryARRAY[1..1000] OF BookCollection of up to 1000 books
numberOfBooksINTEGERCurrent number of valid entries in library

10.3 Files

Why Files?

  • Data must often survive after the program terminates (e.g., student registers, library catalogues).
  • Files provide persistent storage on secondary media (disk, USB, cloud).
  • They allow programs to share data with other programs or later runs of the same program.

Sequential vs. Random Access

  • Sequential access: records are read or written one after another. Simple READ/WRITE loops are used; suitable for most Cambridge exam questions.
  • Random access: the program can jump directly to a particular record (e.g., the 57th book) using SEEK or by reopening the file and reading until the desired index is reached. Random access is not required for the 9618 exam but understanding the concept helps avoid logical errors.

File Declaration Syntax (Cambridge pseudocode)

DECLARE bookFile : FILE OF Book

Opening a File – Modes

  • FOR READ – open for reading; file must already exist.
  • FOR WRITE – open for writing; existing content is erased.
  • FOR APPEND – open for writing, but new records are added after the existing ones.

Sequential Access Example – Reading a Specific Record (Random‑access style)

PROCEDURE readBookByIndex(fileName : STRING, index : INTEGER) RETURNS Book
    DECLARE bookFile : FILE OF Book
    DECLARE temp : Book
    OPEN fileName FOR READ AS bookFile
    FOR i ← 1 TO index DO
        READ bookFile INTO temp
        IF EOF(bookFile) THEN
            CLOSE bookFile
            RETURN null          // index out of range
        ENDIF
    ENDFOR
    CLOSE bookFile
    RETURN temp
ENDPROCEDURE

Common File Pitfalls

  • Opening a file in WRITE mode when you only need to read – this overwrites the file.
  • Forgetting to CLOSE a file – may lead to data loss or file‑handle exhaustion.
  • Not checking EOF before a READ – can cause run‑time errors.
  • Assuming a file is always present; always handle the “file not found” situation in exam code with a comment.

10.4 Abstract Data Types (ADTs)

What is an ADT?

An abstract data type defines a set of values and the operations that can be performed on those values, without specifying how the operations are implemented. In the Cambridge syllabus the focus is on the logical behaviour of three ADTs:

  • Stack – LIFO (last‑in, first‑out). Primary operations: PUSH, POP, TOP, IS_EMPTY.
  • Queue – FIFO (first‑in, first‑out). Primary operations: ENQUEUE, DEQUEUE, FRONT, IS_EMPTY.
  • Linked List – a chain of nodes where each node contains data and a reference to the next node. Primary operations: INSERT, DELETE, SEARCH, TRAVERSE.

Implementing ADTs with Arrays (Cambridge‑style pseudocode)

Stack Using an ARRAY

DECLARE stack : ARRAY[1..MAX] OF INTEGER
DECLARE top : INTEGER ← 0

PROCEDURE push(value : INTEGER)
    IF top = MAX THEN
        // stack overflow – handle as required
    ELSE
        top ← top + 1
        stack[top] ← value
    ENDIF
ENDPROCEDURE

FUNCTION pop() RETURNS INTEGER
    IF top = 0 THEN
        // stack underflow – handle as required
        RETURN -1
    ELSE
        pop ← stack[top]
        top ← top - 1
    ENDIF
ENDFUNCTION

Queue Using an ARRAY (circular technique)

DECLARE queue : ARRAY[1..MAX] OF INTEGER
DECLARE front, rear, count : INTEGER ← 0

PROCEDURE enqueue(value : INTEGER)
    IF count = MAX THEN
        // queue full
    ELSE
        rear ← (rear MOD MAX) + 1
        queue[rear] ← value
        count ← count + 1
    ENDIF
ENDPROCEDURE

FUNCTION dequeue() RETURNS INTEGER
    IF count = 0 THEN
        // queue empty
        RETURN -1
    ELSE
        front ← (front MOD MAX) + 1
        dequeue ← queue[front]
        count ← count - 1
    ENDIF
ENDFUNCTION

Linked List – Conceptual Overview (no full code required for the exam)

  • Each node contains: data : <type> and next : POINTER TO Node.
  • Operations manipulate the next references rather than array indexes.
  • Advantages: dynamic size, easy insertion/deletion at any position.
  • Disadvantages: additional memory for pointers, no direct random access.

Why ADTs Matter for the Syllabus

  • They develop algorithmic thinking – students must choose the most suitable structure for a given problem.
  • Understanding the abstract behaviour helps when the exam asks for “explain what the operation does” without requiring full implementation.
  • Many past‑paper questions involve converting a real‑world scenario into a stack, queue or linked list description.

10.5 Summary Checklist for the Exam

  1. Identify every piece of data and decide whether it is INTEGER, REAL, CHAR, STRING, BOOLEAN or DATE.
  2. Group related fields into a RECORD and write a clear identifier table.
  3. If you need several records, declare an ARRAY of that record type and include an identifier table for the array.
  4. When data must survive beyond program execution, use a FILE. State the purpose, the mode (READ/WRITE/APPEND) and show at least one OPEN/READ/WRITE/CLOSE sequence.
  5. For algorithmic questions, be ready to write simple array loops, a bubble‑sort, a linear‑search, and basic ADT operations (push/pop, enqueue/dequeue).
  6. Check for common pitfalls – overflow, leading‑zero loss, out‑of‑bounds array access, file mode errors, and uninitialised variables.
  7. Map your answer to the assessment objectives: terminology (AO1), justification of type choice (AO2), and correct implementation (AO3).
Suggested diagram: Memory layout of the Student record showing the byte offset of each field (illustrative only).

Create an account or Login to take a Quiz

84 views
0 improvement suggestions

Log in to suggest improvements to this note.