amazon.co.ukExam-focused AQA 7517, OCR H446 and WJEC/Eduqas revision for data representation: binary and hex, two's complement, floating point, ASCII/Unicode, bitmaps, vectors, sound sampling and RLE/dictionary compression with worked conversions.
Binary and hex conversion (AQA 4.3.1, OCR 1.4.1) must be automatic — it underpins two's complement and floating point questions. The anchor fact: one hex digit = exactly 4 bits, so split binary into nibbles:
1101 1010 -> D A (0xDA) 0x2F -> 0010 1111
Denary-to-binary by repeated subtraction of powers of 2 (128, 64, 32, 16, 8, 4, 2, 1), or division by 2 reading remainders upwards. Worked: 214 = 128+64+16+4+2 = 11010110. Binary addition with carries: 0110 + 0111 = 1101 (6+7=13). Overflow occurs when a result needs more bits than the register: adding 1100 (12) + 0100 (4) in 4 bits gives 1 0000 — the 5th bit is discarded, leaving 0000 (wrong, expected 16): state this in 'explain overflow' questions.
Two's complement (AQA 4.3.2): negative numbers invert bits and add 1. For 8 bits the MSB carries weight −128, so values run −128 to +127:
To encode -83 in 8 bits: +83 = 01010011 flip bits = 10101100 add 1 = 10101101 -> -83 To decode 10110100: MSB negative weight: -128 remaining bits: 32 + 16 + 4 = 52 value = -128 + 52 = -76
Alternative decode rule (faster in exams): read the MSB as negative weight and all other bits positively — one pass, no flipping. Conversion back from a negative: subtract 1 then flip, or flip then add 1 — both give the magnitude. Signed addition works with ordinary carries; the final carry out of the MSB is discarded and the result is correct: 11111110 (−2) + 00000011 (3) = 1 00000001 → discard carry → 00000001 (+1). Correct. Sign and magnitude contrast (one-marker): the MSB is a sign flag and the rest the magnitude; it has two representations of zero (00000000 and 10000000) and awkward addition, which is why two's complement is used.
Binary shifts (OCR 1.4.1): left shift multiplies by 2 per place, right shift divides (losing the fractional bits — rounding towards zero); in two's complement, arithmetic right shift preserves the sign bit. Overflow in signed addition is detected by carries into but not out of the MSB, or vice versa — the sign flips wrongly (positive + positive = negative), which is the examinable symptom.
Floating point (AQA 4.3.5/4.3.6) stores value = mantissa x 2^exponent. The single most examinable trade-off: more mantissa bits = more precision; more exponent bits = more range — moving a bit from mantissa to exponent increases range but loses precision, and vice versa. Quote that sentence and you have the 2-marker.
Converting denary to normalised floating point. Convention used by AQA: mantissa and exponent are two's complement, mantissa written as 0.1xxxx (positive) or 1.0xxxx (negative). Worked: represent 5.5 with a 8-bit mantissa and 4-bit exponent:
5.5 = 101.1 in binary normalise: 0.1011 x 2^3 (move the point 3 places left) mantissa = 01011000 (0.1011 padded) exponent = 0011 (3)
Step-by-step: (1) write 5.5 in binary — 101.1; (2) shift the point so the mantissa starts 0.1: 0.1011 x 2^3 (the point moved 3 left, so exponent 3); (3) store the mantissa in two's complement, padded to 8 bits; (4) store the exponent 3 in 4-bit two's complement. A negative example: −10 = −1010 = 1.0110 x 2^4 — mantissa starts 1.0 (normalised negative), exponent 4.
Converting back: read mantissa (two's complement), apply the exponent as a shift, add up the weights. Mantissa 0.1011000, exponent 0011: 0.1011 shifted 3 right = 101.1 = 5.5.
Normalisation (AQA 4.3.6) exists for two reasons to quote: it gives a unique representation of each value (otherwise 5.5 could be 101.1x2^0 or 10.11x2^1...) and it maximises precision by pushing significant bits to the front of the mantissa. A number is normalised iff a positive mantissa starts 0.1 and a negative mantissa starts 1.0; exams give you a stored number and ask whether it is normalised — check the first two mantissa bits.
Errors: many denary values (0.1, 0.3) have no exact binary expansion, so floating point stores an approximation — this is why 0.1 + 0.2 != 0.3 in code. Absolute error = |approx − exact|; relative error = absolute/exact, usually as a percentage (AQA 4.3.3/4.3.4). Rounding underflows precision at the mantissa's tail; very large exponents overflow to infinity, very small underflow to zero. Also know fixed-point contrast: fast, exact for a fixed scale (money in pence), but a fixed range/precision split — floating point trades both dynamically, which is why it dominates general arithmetic.
ASCII is 7-bit: 128 codes, enough for English letters, digits, punctuation and control codes. 'A' = 65 (01000001), 'a' = 97, and the examinable trick: digit characters are codes 48–57, so code - 48 converts a character digit to its numeric value. Unicode assigns a code point to every character in every script plus emoji; UTF-8 is variable-length (1–4 bytes, ASCII-compatible: the first 128 code points use 1 byte identical to ASCII), UTF-16 uses 2 or 4 bytes. The comparison question: ASCII cannot represent non-Latin scripts (one code set of 128); Unicode's variable-length UTF-8 keeps English text at 1 byte (backward compatible) while allowing any code point — state both halves of the trade-off.
Error detection: a parity bit makes the count of 1s even (even parity) or odd; on receipt the parity is recomputed and a mismatch flags an error. It detects single-bit (odd numbers of) errors but cannot locate or correct them, and even numbers of errors slip through — the exact evaluation to give. A checksum goes further: arithmetic over the bytes (e.g. sum mod 256) sent with the data; stronger detection, still no correction — correction needs redundancy (e.g. retransmission, or error-correcting codes).
Bitmaps store a grid of pixels, each with a colour code. Resolution = width x height in pixels; colour depth = bits per pixel (1-bit = 2 colours, 8-bit = 256, 24-bit = 16.7 million). File size calculation — memorise and practise:
Bitmap: 1024 x 768 pixels at 24-bit colour = 1024 x 768 x 24 bits = 18,874,368 bits = 2,359,296 bytes = 2.25 MiB (divide by 1024 twice)
Bitmap drawbacks to quote: file size grows with resolution x depth regardless of image content, and scaling up loses quality (pixels become visible blocks). Vector graphics store drawing objects: a list such as [circle, x=40, y=60, r=15, colour=red], rendered by the drawing software. Advantages: small files for simple diagrams; scaling to any size with no quality loss (objects are redrawn); each object editable independently. Limitation: unsuitable for photographs — a photo's pixel detail cannot be described as a short list of shapes, so bitmaps win there. The exam comparison is exactly that pairing.
Sound is sampled: an analogue wave's amplitude is measured at a fixed sample rate (Hz, samples per second) and each sample stored at a fixed sample resolution (bits per sample). CD quality: 44,100 Hz, 16-bit, stereo (2 channels). File size:
60 seconds at 44.1 kHz, 16-bit, stereo: 44100 x 16 x 60 x 2 bits = 84,672,000 bits = 10,584,000 bytes ≈ 10.1 MiB
Trade-offs to quote: higher sample rate and resolution capture the wave more faithfully (closer approximation, higher bandwidth sounds) but increase file size proportionally; the Nyquist principle — sample at more than twice the highest frequency present — explains why 44.1 kHz covers the ~20 kHz limit of human hearing. Lower rates introduce aliasing distortion (high frequencies masquerade as low ones).
Compression reduces the number of bits needed to store or transmit data (OCR 1.3.1). Lossless compression reconstructs the original exactly (required for text, code, executables); lossy discards detail humans barely perceive (JPEG, MP3, streaming video) and achieves far higher ratios. The examinable fact: lossless for data where every bit matters, lossy where perceptual approximation is acceptable — with a reason in each case.
Run-length encoding (RLE) — lossless — replaces runs of identical values with (count, value) pairs. Worked example, a 1-bit bitmap row:
Original (24 pixels): 000000001111111100000011 RLE: 8x0, 8x1, 6x0, 2x1 Stored (4 bits per pair): 8,0 8,1 6,0 2,1 -> 32 bits vs 24... loss!
Count the marking subtlety: with 4-bit counts and 1-bit values, each pair costs 5 bits, so four pairs = 20 bits < 24 bits — compressed 24→20 bits. The skill examined is knowing when RLE gains: long runs (flat backgrounds, scans of text, fax images). When data alternates rapidly (ABABAB...), RLE stores a pair per character and expands the file — still lossless, but bigger. Be ready to compute the break-even: with n-bit counts and v-bit values, a run of length k compresses when k x original-bit-depth > n + v.
Dictionary (LZ-family) compression — lossless — builds a dictionary of repeated substrings as it scans, replacing each repeat with a short codeword/index. Worked sketch on the cat sat on the mat:
Scan: 'the ' seen -> dictionary[254] = 'the ' 'the cat sat on the mat' -> the cat sat on [254]mat (second 'the ' replaced by an index)
Repeated phrases collapse to 1-byte (or few-bit) references; the dictionary itself is stored (or rebuilt during decompression, as in LZ77/LZW) so the process is fully reversible. Properties to quote: lossless; excellent on text and structured data with repetition; poor on already-compressed or random data (no repeats to factor out — and can even add overhead); decompression must be able to rebuild or reference the dictionary, so implementations either store it or derive it deterministically.
Evaluation paragraph to reuse in essays: compression trades processing time for space/bandwidth — compressing and decompressing cost CPU, so it pays off when data is stored long-term or transmitted over slow links, and can be counterproductive for data compressed once and used once on a fast local bus. Also connect to error detection: compressed data is more fragile — a single corrupted bit can derail the dictionary, which is why compressed streams carry checksums.