A-Level · Data Representation

Floating Point, Bitwise Ops, Compression, Error Checking

Four genuinely different ways computers manage the raw bits underneath everything else: representing real numbers with limited precision, manipulating individual bits directly, squeezing repeated patterns out of data, and catching when a bit has flipped by accident.

Section 2

Floating point representation

A floating point number is stored as two separate pieces: a mantissa (the significant digits) and an exponent (how far to shift the point), both in two's complement, both normalised so the mantissa uses every available bit of precision. Two formats below, both genuinely used in exam questions.

Mantissa (8 bits, two's complement fraction)

Exponent (4 bits, two's complement integer)

Try one

This format's range

Normalisation walkthrough

Enter any mantissa, even a deliberately un-normalised one, and watch the actual shift-and-adjust-exponent process, one step at a time.

Try one

Exam tips

  • Normalised means the two leftmost mantissa bits always differ (01... for positive numbers, 10... for negative), this maximises how many significant bits are actually used, exactly the same reason scientific notation writes 6.0×10³ rather than 0.006×10⁶.
  • More mantissa bits means more precision (finer distinctions between nearby values). More exponent bits means more range (much larger or smaller magnitudes representable). You cannot improve both without using more bits overall, that's the fundamental trade-off, directly visible switching between the two formats above.
  • Overflow happens when a number's magnitude needs an exponent bigger than the format allows, underflow when it needs an exponent smaller (more negative) than the format allows. Try 500 in the 8+4 format to see overflow happen for real.
  • To normalise: shift the mantissa left, keeping the sign bit fixed, and decrease the exponent by the same amount, this changes how the value is represented without changing the value itself, since ×2 on the mantissa exactly cancels ÷2 on the exponent's effect.
Section 3

Floating point practice exercises

Every exercise below is auto-marked, and every correct answer is computed by the exact same verified functions driving the converter and normalisation tool above, not hand-typed answers that could contain a mistake.

0 / 0 completed
Category:
Difficulty:

Section 4

Bitwise operations

Click any bit below to flip it. Every operation recalculates live, this is genuinely how AND, OR, XOR and NOT behave, bit by bit, no shortcuts.

A

B

Practical masking

Using A above and a mask, try each of these real-world bit tricks.

Exam tips

  • AND with a mask of 1s and 0s checks or clears specific bits (1 keeps the bit, 0 forces it to 0). OR with a mask sets specific bits to 1 without touching the others. XOR with a mask flips exactly the bits marked 1 in the mask, leaving the rest untouched.
  • A left shift by n is equivalent to multiplying by 2ⁿ, a right shift by n divides by 2ⁿ (rounding toward zero), provided no bits are lost off either end.
Section 5

Huffman coding

A real compression algorithm: characters that appear more often get shorter codes, characters that appear rarely get longer ones. Type some text and watch it build the actual code table.

Try one

Exam tips

  • Huffman codes have the prefix property: no complete code is ever the start of a longer code. This is exactly what lets a decoder read a stream of bits unambiguously, without needing any separators between codes.
  • Huffman coding only helps when symbol frequencies are genuinely uneven, text made of equally common characters compresses barely at all, there's no pattern of "common vs rare" for it to exploit.
Section 6

Error detection: parity bits

Click any bit to flip it, simulating a transmission error, and watch whether the parity check actually catches it.

Data bits (click to flip, simulating transmission)

Parity bit (fixed, sent alongside the data)

Controls

Exam tips

  • A single parity bit catches any odd number of flipped bits (1, 3, 5...), but two flipped bits cancel out and go completely undetected, a genuine, well-known limitation, not an edge case to ignore.
Section 7

Checksums in the real world: credit cards and ISBNs

Parity is one specific checksum. Two genuinely widespread ones use modulo arithmetic directly: the Luhn algorithm validates every credit card number, and ISBNs carry their own built-in check digit.

Luhn algorithm (credit cards)

Try one

Exam tips

  • Luhn doubles every second digit counting from the rightmost (check) digit, if doubling pushes a digit above 9, subtract 9 (equivalent to summing its own two digits). The whole card is valid only if the grand total is divisible by 10.
  • This catches the single most common real typing error: transposing two adjacent digits, along with any single mistyped digit, but like any checksum, specific compensating errors can still slip through undetected.

ISBN-10 check digit

Try one

Exam tips

  • Each of the first 9 digits is multiplied by a positional weight counting down from 10 to 2, the check digit is chosen specifically so the whole weighted sum divides exactly by 11, that's a deliberate design choice, not a coincidence.
  • Because a check digit of 10 can't be written as one digit, ISBN-10 uses the letter X to represent it, this is genuinely part of the standard, not an error or special case to work around.
Section 8

Check your understanding