Information Representation
How a computer that only understands 1 and 0 ends up storing your name, a family photo, and your favourite song. Binary number systems, two's complement, multimedia data, and compression, built up from first principles with interactive tools you can actually play with.
Every photo, song, password and line of code on your machine boils down to long strings of 1s and 0s. This chapter is the foundation of AS Level Computer Science 9618 Paper 1: how numbers, text, images and sound get squeezed into binary, how negative numbers survive that squeeze, and how files get compressed so they fit on disks and networks that were never big enough. Nothing here is optional background reading, every subtopic below maps directly onto a line in the Cambridge 9618 syllabus and shows up in Paper 1 exams.
Binary Magnitudes & Prefixes
A computer only ever stores 1s and 0s, so before anything else can make sense you need to know how those bits get counted at scale. Every spec sheet, file size and download speed you have ever seen used one of two competing counting systems, and mixing them up is one of the most common ways to lose easy marks in Paper 1.
Why two systems exist
Storage is physically built in powers of two (a memory chip has 2, 4, 8, 16... address lines), so it is natural for computer scientists to count in powers of 2. Marketing departments, on the other hand, count in the everyday powers of 10 you already know, because "1 terabyte" sounds cleaner and, not coincidentally, sounds bigger than the true binary equivalent. Both systems are still in daily use, so you need both.
- Kilo (K) = 103 = 1,000
- Mega (M) = 106 = 1,000,000
- Giga (G) = 109 = 1,000,000,000
- Tera (T) = 1012 = 1,000,000,000,000
- Kibi (Ki) = 210 = 1,024
- Mebi (Mi) = 220 = 1,048,576
- Gibi (Gi) = 230 = 1,073,741,824
- Tebi (Ti) = 240 = 1,099,511,627,776
Number Systems & Conversion
The 9618 syllabus expects you to move confidently between four number systems. You will not just be asked to define them, you will be asked to convert between them under exam pressure, so the goal here is fluency, not just recognition.
| System | Base | Digits used | Notation you'll see |
|---|---|---|---|
| Binary | 2 | 0, 1 | 0b1010 or a trailing B in pseudocode |
| Denary (decimal) | 10 | 0 to 9 | No prefix, this is the default |
| Hexadecimal | 16 | 0 to 9, A to F | 0x1F or a leading & in pseudocode |
| Binary Coded Decimal | 10 (encoded in binary) | 0 to 9, each in its own 4 bits | Each denary digit becomes a 4-bit group |
How positional (place value) works in any base
Every number system you will meet in this course is positional: each digit's value depends on where it sits. In binary, each position is worth double the one to its right, starting from 1 on the far right. An 8-bit binary number therefore has place values of 128, 64, 32, 16, 8, 4, 2 and 1. To convert binary to denary, you simply add up the place values of every position holding a 1.
Converting the other way: denary, binary or hex to any base
To convert denary to binary, repeatedly find the largest place value that fits, subtract it, and move on, or use the classic "divide by 2, read remainders bottom to top" method. To convert binary to hex, group the bits into nibbles of 4 (see section 6 for a full walkthrough). Use the tool below for arbitrary numbers rather than just 8 bits.
Use the "does it fit?" method against the standard 8-bit place values.
Binary Addition & Subtraction
A CPU has no separate "subtract" circuit tucked away next to its "add" circuit. Building two different pieces of hardware would waste transistors, so real processors do both operations with the same adder circuit, and subtraction is simply addition in disguise. Understanding that trick is exactly what this section, and the two's complement section right after it, is building towards.
Binary addition, column by column
Binary addition works exactly like the denary addition you already do, except there are only four possible column sums to memorise:
0 + 0 = 00 + 1 = 11 + 1 = 10(write 0, carry 1)1 + 1 + 1 = 11(write 1, carry 1, this happens when a carry lands on a column that is already 1 + 1)
Overflow
Overflow happens when the true result of an addition needs more bits than the register you are storing it in actually has. An 8-bit register can only hold values from 0 to 255 unsigned, or -128 to +127 in two's complement, so if the maths produces a result outside that range, the extra bit simply falls off the end and the stored answer is wrong.
- Unsigned overflow: a carry is generated out of the most significant bit with nowhere left for it to go.
- Signed (two's complement) overflow: adding two positive numbers produces a result that looks negative, or adding two negative numbers produces a result that looks positive. The rule examiners want: overflow has occurred if the carry into the sign bit does not equal the carry out of the sign bit.
127 is the largest positive number an 8-bit two's complement register can hold. Add 1 to it and watch it break.
Binary subtraction: addition of a negative number
Rather than build separate subtraction circuitry, computers rewrite A − B as A + (−B), convert B into its two's complement (negative) form, and then run it through the ordinary adder. Any carry that gets generated out of the very top (sign) bit is simply discarded, it does not represent an overflow here, it is an expected side effect of the method.
One's & Two's Complement
So far every number we have stored has been positive. Real programs need negative numbers too: temperatures below freezing, bank balances, offsets in memory. The syllabus wants you to know two ways of representing them in binary, and to understand why one of them completely took over in real hardware.
One's complement
One's complement is the simple option: to make a number negative, invert every bit (every 0 becomes a 1, every 1 becomes a 0). It is quick to compute but it has two awkward properties that stopped it from being used in modern processors: it has two representations of zero (00000000 and 11111111), and doing arithmetic with it requires an extra "end-around carry" correction step.
Two's complement: the one computers actually use
Two's complement fixes both problems with one extra step: invert every bit exactly as before, then add 1 to the result. This gives every value, including zero, exactly one binary pattern, and it means the same adder circuit used for addition can be reused for subtraction with no special-case logic at all, which is exactly the trick from the previous section.
Ranges: how many values fit in 8 bits
- Minimum: 0
- Maximum: 255 (28 − 1)
- Total distinct values: 256
- No negative numbers possible
- Minimum: -128
- Maximum: +127
- Total distinct values: 256
- Most significant bit = sign bit (1 means negative)
Notice both ranges hold exactly 256 values, that never changes since 8 bits can only ever form 28 unique patterns. What changes is how those 256 patterns get interpreted. This is a critical exam idea: the same bit pattern, say 11111111, means 255 if you are told to treat it as unsigned, but means -1 if you are told to treat it as two's complement. The bits never lie, but they need context.
Binary Coded Decimal (BCD)
Straight binary is the most compact way to store a number, but it is a nightmare for a device that only ever needs to display denary digits, like a digital clock or a calculator. BCD trades away some of that compactness in exchange for a much simpler translation back to the digits humans actually read.
How BCD works
BCD encodes each denary digit separately, using exactly 4 bits per digit, rather than converting the whole number to binary at once. This is the single most common misconception students have about BCD, so compare it directly against ordinary binary below.
Because each 4-bit group only ever needs to represent a digit from 0 to 9, the patterns 1010 through 1111 (10 to 15) are never valid in BCD. If you ever see one of those six patterns inside a BCD number, that is a broken or corrupted value.
1010, 1011, 1100, 1101, 1110, 1111 can never legally appear as a BCD digit group. Spotting one of these in an exam question is a quick way to identify an error in the data.
Practical applications of BCD
BCD trades storage efficiency for accuracy and simplicity of display, which is exactly what these situations need:
- Digital clocks and seven-segment displays
- ATMs and point-of-sale systems handling currency
- Calculators
- Any embedded system where digit-by-digit display matters more than saving a few bits
- Converting binary back to individual denary digits for a display is slow and error-prone
- BCD avoids rounding errors that can creep in with binary representations of decimal currency values
- Each digit can be decoded and sent to its own display segment independently
Hexadecimal
Reading a 32-bit binary number is exhausting for a human, and typing 32 characters accurately is even worse. Hexadecimal exists purely as a compact, human-friendly way to write binary down, because each single hex digit maps onto exactly 4 bits with nothing left over.
| Denary | Binary | Hex | Denary | Binary | Hex |
|---|---|---|---|---|---|
| 0 | 0000 | 0 | 8 | 1000 | 8 |
| 1 | 0001 | 1 | 9 | 1001 | 9 |
| 2 | 0010 | 2 | 10 | 1010 | A |
| 3 | 0011 | 3 | 11 | 1011 | B |
| 4 | 0100 | 4 | 12 | 1100 | C |
| 5 | 0101 | 5 | 13 | 1101 | D |
| 6 | 0110 | 6 | 14 | 1110 | E |
| 7 | 0111 | 7 | 15 | 1111 | F |
Converting binary to hex: group into nibbles
Because 16 = 24, every hex digit corresponds to exactly one group of 4 bits, called a nibble. To convert, split the binary number into nibbles starting from the right, pad the leftmost group with leading zeros if needed, then convert each nibble to its hex digit independently.
Practical applications of hexadecimal
- Memory addresses in low-level programming and debugging
- MAC addresses (e.g.
3C:15:C2:9A:4B:01) - HTML/CSS colour codes (e.g.
#FF5733) - Assembly language operands and machine code dumps
- IPv6 addresses
- A 32-bit binary address is 32 characters long, its hex equivalent is only 8
- Far fewer transcription errors when a person is reading or typing it
- The 4-bit-per-digit mapping means conversion is instant, with no arithmetic required
Character Sets: ASCII & Unicode
A computer cannot store the letter "A" directly, it can only store binary. A character set is simply an agreed table that maps every character you might want to type onto a specific binary number, so that every device reading that number agrees on which character it represents.
- 128 characters, codes 0 to 127
- Extended ASCII stretches this to 256 characters using the full 8 bits (1 byte)
- Covers English letters, digits and common symbols only
- 'A' = 65, 'a' = 97, '0' = 48
- Uses exactly 1 byte per character
- Over 1 million possible code points
- Covers every world language plus emoji and symbols
- UTF-8 uses a variable 1 to 4 bytes per character
- Backwards compatible with ASCII (the first 128 codes match exactly)
- The de facto standard for the modern web
The reason Unicode had to exist at all is that ASCII's 128 or 256 slots simply are not enough characters to represent Chinese, Arabic, Cyrillic, emoji and every other writing system in the world at once. Unicode solves this by using a much larger address space, and by making that address space variable-length (UTF-8) so that plain English text does not waste extra bytes it does not need.
Bitmap Images
Photos, screenshots and scans are all stored the same way underneath: as a grid of tiny coloured dots, each one a binary number. Understanding exactly what is being counted here is what lets you calculate, and explain the trade-offs of, file size.
Key terms
| Term | Definition |
|---|---|
| Pixel | A single dot in the image grid, the smallest controllable unit of a bitmap ("picture element") |
| Image resolution | The number of pixels that make up the image, e.g. 1920 × 1080 |
| Screen resolution | The number of pixels per inch (PPI) a display is able to show |
| Colour depth / bit depth | The number of bits used to store the colour of each pixel, e.g. 8-bit gives 256 possible colours |
| File header | Metadata stored at the start of the file: width, height, colour depth and other information needed to decode the pixel data that follows |
Calculating bitmap file size
Every pixel needs the same number of bits to store its colour, so the total file size is just the pixel count multiplied by how many bits each pixel costs.
What happens if you change the resolution or the colour depth
- More pixels means more detail can be captured, a sharper, higher-quality image
- File size grows in direct proportion to the pixel count, doubling both width and height quadruples the file size
- Displaying a low-resolution image on a high-resolution screen makes it look blocky or blurred
- More bits per pixel means more distinct colours are available, smoother gradients and shading
- File size is directly proportional to colour depth, doubling the colour depth doubles the file size
- Reducing colour depth causes colour banding (posterisation), visible harsh edges between colour bands where a smooth gradient used to be
Vector Graphics
A bitmap stores what an image looks like. A vector graphic stores instructions for how to draw it, a fundamentally different approach that solves the scaling problem bitmaps struggle with.
Key terms
| Term | Meaning | Example |
|---|---|---|
| Drawing object | A shape defined mathematically rather than pixel-by-pixel | Circle, rectangle, line, curve |
| Property | An attribute attached to a drawing object that controls how it is rendered | Radius = 50, Fill = blue, Stroke width = 2px |
| Drawing list | The ordered list of every drawing object that makes up the complete image, stored inside the file | The vector file format itself is essentially this list |
To display a vector image, software reads the drawing list and recalculates every shape from its mathematical definition at whatever size is needed. That recalculation step is exactly why vector graphics can be scaled to any size, tiny icon or huge billboard, with no loss of quality whatsoever, while a bitmap enlarged past its native resolution just becomes a blurry grid of oversized pixels.
Choosing between bitmap and vector
- The image is a photograph with complex, continuous colour variation
- You need pixel-level editing (retouching, filters)
- The image has gradients or heavy texture
- It will be displayed at one fixed size
- It is a logo or icon that needs to scale to many sizes
- It is a technical or engineering diagram
- It is text or typography
- It needs infinite zoom with no loss of quality
Sound Encoding
Real sound is a continuous, smoothly varying vibration in the air, an analogue signal. A computer can only store discrete binary numbers, so to record sound digitally we have to measure that continuous wave at regular moments in time and store each measurement as a binary value. This process is called sampling.
Sampling: turning a wave into numbers
| Term | Definition | Effect of increasing it |
|---|---|---|
| Sampling | Measuring the amplitude (height) of the sound wave at a regular interval and storing that value in binary | — |
| Sampling rate | The number of samples taken per second, measured in Hertz (Hz) | Captures the wave more faithfully and at higher frequencies, but produces a larger file |
| Sampling resolution | The number of bits used to store each individual sample (its bit depth) | Records finer differences in volume/amplitude, but produces a larger file |
What happens if the rate or resolution is too low
If the sampling rate is too low, fast changes in the wave get missed entirely between samples, the played-back sound loses high-frequency detail and can sound muffled or distorted, an effect called aliasing. If the sampling resolution is too low, each sample gets rounded to the nearest available level, introducing quantisation error, audible as background hiss or a "grainy" quality. Both problems trade accuracy for a smaller file, and both are the reason low-bitrate audio sounds noticeably worse than a CD.
Calculating sound file size
Compression
Every calculation in this chapter so far has produced an uncompressed, theoretical file size. Real files are almost always smaller, because compression re-encodes data to take up less space.
Why compression is needed
- Storage is limited. Phones, cameras and servers all have a finite amount of disk space, compression lets more files fit.
- Bandwidth is limited. Networks, including the internet, can only move a certain number of bits per second, a smaller file transfers faster.
- Streaming needs to keep up in real time. Video and music services must deliver data at least as fast as it plays back, which is only realistic once the file is compressed.
Lossy vs. lossless: the fundamental choice
- Original data is fully and exactly recoverable
- Zero quality loss, ever
- Achieves a smaller size reduction than lossy methods
- Used for: text files, program code, PNG images
- Example methods: run-length encoding (RLE), Huffman coding
- Some data is permanently discarded and cannot be recovered
- Quality degrades, though often imperceptibly to humans
- Achieves a much greater size reduction
- Used for: photographs (JPEG), music (MP3), video
- The process cannot be reversed once applied
Run-length encoding (RLE): compressing repetition
RLE is a lossless technique that replaces a run of consecutive, identical values with a short (count, value) pair instead of writing the value out every single time. It works brilliantly on images with large flat areas of a single colour, like simple clipart or logos, and is almost useless on photographs, where neighbouring pixels rarely repeat exactly.
How each type of file gets compressed
The syllabus expects you to describe compression for four specific file types. Each one uses a different technique because each one has different redundancy to exploit.
| File type | Compression used | Why |
|---|---|---|
| Text file (.txt) | Lossless, e.g. Huffman coding or dictionary-based methods (ZIP) | Every character matters, losing even one changes the meaning of the text. Common letters/words are given shorter codes to shrink the file without losing anything |
| Bitmap image (.bmp) | Lossless, e.g. RLE or PNG's compression | RLE exploits large runs of identical pixels in simple images; PNG-style methods find repeating patterns without discarding any pixel data |
| Vector graphic (.svg) | Lossless | The file is already just a compact list of mathematical instructions, there is no pixel data to lose. Compression here just re-encodes the instruction list more efficiently (e.g. removing redundant whitespace or repeated values) |
| Sound file (.mp3) | Lossy | Removes frequencies that are outside the range of typical human hearing, or masked by louder nearby sounds, so the file shrinks dramatically with minimal perceived quality loss |
Practice Questions
Try each of these before reading the model answer. They are written in the same style as Cambridge 9618 Paper 1 questions.
Manufacturers state capacity using decimal (SI) prefixes, where 1 TB = 1012 bytes. Operating systems report capacity using binary (IEC) prefixes, where 1 TiB = 240 bytes, a larger number of bytes for the "same" labelled unit. Because 240 is bigger than 1012, dividing the same physical byte count by the larger binary unit produces a smaller reported number.
52 in binary is 00110100. Invert every bit to get 11001011. Add 1 to get 11001100.
-52 = 11001100
01100100 = 100 and 01000001 = 65. Their true sum is 165, but the maximum positive value an 8-bit two's complement register can hold is 127. Adding the two positive numbers produces a result with the sign bit set to 1 (appears negative), so overflow does occur.
The logo should be stored as a vector graphic. A vector stores the logo as a drawing list of mathematical shapes and properties rather than a fixed pixel grid, so it can be re-rendered at any size, from a tiny favicon to a large banner, with no loss of quality and no need to store multiple versions. A single bitmap could not do both well: one small enough for a favicon would look pixelated when enlarged for the banner, and one large enough for the banner would be an unnecessarily large file for a favicon.
1. The file size (and therefore the required bit rate) will decrease, so it streams more easily on a slow connection. 2. Sound quality will decrease, high-frequency detail will be lost because the wave is being measured less often, which can make the audio sound duller or muffled.
