IB Computer Science HL — All Flashcards

It controls and coordinates the CPU: it fetches and decodes instructions and sends control signals telling the other components what to do and when. It does no calculating itself.

It performs all arithmetic operations (add, subtract, multiply, divide) and logic operations (AND, OR, NOT, and comparisons) on data.

The address of the **next** instruction to be executed. It advances after each instruction is fetched.

The MAR holds the **address** being accessed; the MDR holds the **value** travelling to or from memory. Address versus data.

The instruction currently being executed, held there while the CU decodes and carries it out.

The number the ALU is working on — both the value going in and the answer coming out. ADD 5 turns a 12 in the accumulator into 17, in the same register.

**Address bus** — the memory address (one-way, CPU → memory). **Data bus** — the data or instruction itself (two-way). **Control bus** — the CU's commands and timing signals (two-way).

Only work that can be divided between cores benefits. If each step depends on the previous result, the work cannot be split and extra cores sit idle.

Registers sit inside the CPU and can be reached almost instantly, whereas RAM is much slower. Holding working values in registers stops the ALU waiting on memory.

To perform many simple calculations at the same time. It has thousands of small cores, which suits work made of many identical independent sums — pixels, machine learning, simulations.

A CPU has a few powerful cores that handle complicated varied work in order. A GPU has thousands of simple cores that do the same calculation simultaneously.

Machine learning (multiplying huge grids of numbers) and large simulations (updating millions of independent points). Both repeat one calculation across many values.

When the work is a chain of steps that each need the previous answer. Nothing can run in parallel, and GPU cores are individually weaker than CPU cores.

The CPU runs the program, decides what needs doing, sends the repetitive part and its data to the GPU, and collects the result when it is finished. The GPU never chooses its own work.

A **CPU** has a few powerful cores optimised for **latency** on one stream. A **GPU** has thousands of simple cores optimised for **throughput** on many values at once.

Its cores run in **lockstep** on the same instruction, so a branch forces some to idle while the others proceed.

**Are the operations independent?** Can they run in any order, simultaneously, without needing each other's results?

Training is enormous **parallel matrix arithmetic** over a whole dataset. Inference is one input, one pass — small enough for a CPU or a phone.

If the work is sequential or branch-heavy it cannot parallelise, each GPU core is slower than a CPU core, and the data must be **copied there and back**.

Registers, then cache (L1, L2, L3), then RAM. Each step holds more and takes longer to reach.

To hold recently used data and instructions in a small, very fast store close to the CPU, so most requests avoid the slower trip to RAM.

A hit means the value is already in cache, so no trip to RAM is needed. A miss means it is not, so it is fetched from RAM and copied into cache for next time.

RAM is a large volatile working space holding programs in use; it empties when power is lost. ROM is small, non-volatile and read only, holding the start-up program.

Because programs tend to reuse the same values shortly afterwards, so caching it turns the next request into a hit.

Fetch the next instruction from memory, decode it in the control unit, then execute it — usually a calculation in the ALU. The cycle then repeats.

The PC holds the address, which is copied to the MAR. Memory returns the instruction into the MDR, and it moves to the IR. The PC is then increased.

During fetch. A jump instruction works by writing a new address into the PC during execute — increasing it afterwards would overwrite the jump.

The control unit reads the instruction held in the IR, works out which operation is needed, and sends control signals to the parts that will carry it out.

All three: the address bus carries the address out, the control bus carries the read signal, and the data bus brings the instruction back.

Overlapping the stages of the fetch–decode–execute cycle, so one instruction executes while the next is decoded and a third is fetched.

**No.** It still passes through every stage. What improves is **throughput** — how many complete per second.

**k + (n − 1)** stage-times — the k being the one-off cost of filling the pipeline.

**Branches** (the next instruction is unknown), **data dependencies** (waiting for a result), **resource conflicts** (two stages want the same hardware).

It overlaps more work, but a **wrong branch prediction costs more** because there is more to discard and refill.

Non-volatile storage that keeps data when the power is off. RAM empties at power-off, so anything kept permanently — files, programs, the operating system — lives here.

An SSD uses flash memory with no moving parts: faster, quieter, more robust, but dearer per gigabyte. An HDD uses a spinning magnetic disk with a moving head: slower and more fragile, but much cheaper for the capacity.

Portable SSD/HDD for backups and large files; flash drives or memory cards for carrying small amounts; optical discs for distributing identical content cheaply. NAS puts drives on a network for shared access.

Flash storage soldered onto the board of phones, tablets and budget laptops. Compact and inexpensive, but slower than an SSD and not replaceable.

Weigh capacity, speed, portability, cost and how many people need access at once. The right answer follows from the situation, not from which is newest.

Storing the same data in fewer bits. It works because real files repeat themselves, and smaller files need less storage and travel faster over a network.

Lossless can rebuild the original exactly — nothing is discarded, only written more briefly. Lossy permanently removes detail people are unlikely to notice, saving far more space but irreversibly.

Each run of identical values is replaced by a count and the value. A row of six white pixels is stored as '6 white' — two values instead of six. Expanding it restores every original pixel.

When neighbouring values rarely repeat, such as a detailed photograph. Most runs are length one, so storing a count beside every value adds data rather than saving it.

Text, code and spreadsheets need lossless — one altered character can change the meaning. Photographs, music and video use lossy, because small losses go unnoticed and the saving is much greater.

Renting computing from a provider over the internet instead of buying and running the machines yourself. You pay for what you use and the provider keeps the hardware working.

How far up the stack the provider takes over. IaaS gives you a machine and you install the OS upwards. PaaS runs the OS and runtime, and you supply your program. SaaS is the finished program — you just sign in.

When it needs to choose the operating system or its version — for software with unusual requirements — and has technical staff able to configure and maintain the machines.

When it needs a finished tool and has no technical staff. The provider handles updates, patching and backups, and the service is usable immediately.

Every layer you hand to the provider saves you work and removes a choice. Towards IaaS: more control, more responsibility for patching and setup. Towards SaaS: ready in minutes, but you accept the provider's features and versions and moving away later is hard.

Write the column values above it — 128 64 32 16 8 4 2 1 — and add the columns that have a 1 under them. 10110101 = 128 + 32 + 16 + 4 + 1 = 181.

Take the biggest column value that fits, subtract it, and repeat with what is left. 181: 128 fits (53 left), 32 fits (21), 16 fits (5), 4 fits (1), 1 fits (0) — so 10110101. Add the columns back to check.

Four bits can hold the values 0 to 15, which is exactly the range of a single hex digit (0 to F). So any four bits swap cleanly for one character.

Group the bits in fours starting from the right, padding the leftmost group with zeros, then turn each group into its digit. 101101 is 0010 1101, which is 2D.

A = 10, B = 11, C = 12, D = 13, E = 14, F = 15. To convert two hex digits to decimal, multiply the left by 16 and add the right: B5 = 11 × 16 + 5 = 181.

Because the meaning is an agreement held by the program reading them, not a property of the bits. 01000001 is 65 read by place value and A read through a character set.

Each character is given a number by an agreed character set — 65 for A in ASCII — and that number is stored in binary. A string is those numbers one after another, so CAT is 67, 65, 84.

ASCII uses one byte per character and covers English. Unicode assigns numbers to every writing system, using more bytes per character where it needs them.

The picture is divided into a grid of pixels, and each pixel's colour is stored as numbers — one byte for greyscale, or three bytes for red, green and blue. More pixels means proportionally more storage.

Audio: the height of the sound wave measured thousands of times a second, each measurement stored as a number. Video: a complete image 24 to 60 times a second, plus the audio — which is why video files are the largest.

A component that takes one or two bits in and gives one bit out, always the same way for the same inputs. Gates wired together are what a CPU is physically built from.

AND: only when both inputs are 1. OR: when at least one input is 1. NOT: when the single input is 0. XOR: when the two inputs are different.

Invert the output. AND with a circle is NAND, OR with a circle is NOR, XOR with a circle is XNOR — each is the original table with every output flipped.

When both inputs are 1, OR gives 1 but XOR gives 0. XOR means the inputs are different, so it rules out the both-on case. A rule saying 'one or the other but not both' is XOR.

AND: a microwave runs only if the door is closed and the timer is running — the rule says 'both'. OR: a car alarm sounds if any one of several doors opens — the rule says 'any'.

Two to the power of the number of inputs: 2 inputs give 4 rows, 3 give 8, 4 give 16. The rows are counted upwards in binary, so no combination is missed.

Give every gate its own column and work left to right. Fill the input columns first, then each gate column using only its own inputs, then combine those for the final output.

Use · for AND, + for OR and NOT for inversion. A circuit where an AND of A and B feeds an OR alongside an inverted C is X = (A·B) + NOT C.

The outputs are arranged so neighbouring squares differ by one variable only. Circle the largest groups of adjacent 1s in sizes 1, 2, 4 or 8; for each circle keep the variables that stay constant and drop those that change.

A shorter expression is a circuit built from fewer gates — less hardware, less power consumption and fewer things to fail. For example A·B + A·(NOT B) simplifies to just A, needing no gates at all.

Write the Boolean expression first, draw the inputs down the left, draw the gates inside the brackets first, then feed their outputs into the final gate and label the output line.

A flat-backed D shape is AND; a curved back with a pointed front is OR; a triangle with a circle is NOT. A circle on any output inverts it; an extra curve at the back makes it exclusive.

Whichever is inside the brackets. Its output feeds the gate outside them. Drawing them the other way round reverses the logic and is the most common mistake.

A + A·B = A, which drops a whole term when A alone is already enough, and A·(B + C) = A·B + A·C, which lets you factor out what is common. A repeated letter is the clue to look for.

Build the truth table for the original expression and for the simplified one. Every row must match. This catches nearly every error, and a shorter expression is never proof on its own.

It sits between programs and hardware doing two jobs: abstraction — giving programs one standard way to ask for anything — and resource management, deciding who gets the CPU, memory and devices, and when.

Programs ask for what they need in one standard way whatever hardware is underneath. A program says 'save this file' without knowing which drive it is or how that drive works.

Because every program would then need to know every model of disk, printer and network card, and adding new hardware would mean rewriting all of them. With an OS, only a driver is added.

It gives each program its own region of memory, queues their requests for shared devices, and refuses direct access to hardware or to its own memory — programs have to ask.

A driver is added to the operating system, teaching it how to speak to that model. Every existing program keeps making the same standard request, so all of them work with it immediately.

Memory management, scheduling, file system, device management, security, accounting, graphical user interface, virtualization and networking — all running in the background at once.

Gives each program its own region of memory, tracks what is free, reclaims it when a program closes, and refuses any attempt to read or write memory belonging to another program.

Talks to every device through its driver and queues requests, so two programs never try to use one device at the same moment and no program needs to know the device's model.

Making one physical machine appear to be several separate ones, each running its own operating system and unable to reach the others. It is how a single server hosts many customers.

Each program has its own memory region and access outside it is refused; no program can address hardware directly. When one fails the OS stops it and reclaims its memory, leaving everything else running.

The rule the operating system uses to decide which process gets the CPU next, and for how long. A core runs one process at a time, so switching fast enough makes them appear simultaneous.

FCFS runs each process to completion in arrival order — simple, but one long job blocks everything behind it. Round robin gives each a fixed time slice then moves on, so everyone gets an early first turn, at the cost of time spent switching.

The highest-priority waiting process runs next, so urgent work always goes first — essential for real-time systems. The risk is starvation: a low-priority process may never run if urgent work keeps arriving.

Raising a process's priority the longer it has been waiting, so that even the lowest-priority work eventually reaches the front of the queue. It is the usual fix for starvation.

Processes are sorted into separate queues by what they are — interactive work in one, background batch work in another — and each queue gets its own scheduling rule and its own share of CPU time.

With polling the CPU repeatedly asks the device whether it is ready. With interrupts the device signals the CPU when it is ready, so the CPU can work uninterrupted until then.

The CPU finishes its current instruction, saves where it was, runs a short routine that deals with the device, then restores the saved state and carries on. That saving and restoring is the overhead.

When the device is almost always ready, so nearly every check succeeds and you avoid saving state thousands of times a second; and when a guaranteed response time is needed, since the delay is bounded by the checking interval.

Because the CPU can sleep between events, which uses very little power. Polling forces it awake to run checks that mostly find nothing, shortening battery life for no benefit.

Interrupts are raised by devices, so a faulty or malicious device can raise them constantly and leave the CPU no time for other work. Polling cannot be flooded, because the CPU decides when to look.

**Concurrency.** Several tasks are in progress but only one executes at any instant. Parallelism needs more than one core.

**Save** the running process's registers and program counter, choose the next, **restore** its state, resume it exactly where it stopped.

The incoming process finds the **cache full of the previous one's data**, so its first memory accesses miss and are slow.

**Mutual exclusion, hold-and-wait, no pre-emption, circular wait** — all four at once. Break any one and deadlock cannot occur.

**Deadlock**: nobody can ever proceed. **Starvation**: the system runs fine but one process never gets a turn — fixed by **ageing**.

**Sensor** → **ADC** → **microprocessor** → **actuator** → **feedback path** back to be measured again.

**Open** acts without checking the result (a heater on a timer). **Closed** measures the result and acts on the **error** (a thermostat).

The ability to correct **disturbances nobody predicted**. An open loop follows a plan; a closed loop pursues a goal.

A deliberate gap between the switch-on and switch-off points, so the actuator does not cycle constantly around the target and wear out.

A correct answer **too late is a wrong answer** — braking 200 ms late is a crash. It must respond within a guaranteed time, not an average one.

The **consequence of being wrong**. The loop is always the same — sense, decide, act, measure — but a pacemaker and a thermostat face very different costs of failure.

A failed sensor reading **zero looks like a genuine zero**. Comparing several means a disagreeing reading is treated as a fault rather than obeyed.

What the system does when it **cannot determine the situation** — a train applies the brakes, because stopping is safe and continuing is not.

**Hard**: a missed deadline is a failure (braking, airbag). **Soft**: it degrades quality (a dropped video frame).

People trusting a usually-correct system and **stopping checking it**, so the rare failure passes unchallenged.

A **compiler** translates the whole program in advance into an executable. An **interpreter** translates and executes **line by line**, every run.

**Compiler**: before the program runs, all at once. **Interpreter**: only when execution **reaches that line**.

Translation happens **while it runs**, every time. Compiled code was already machine code before it started.

A compromise — compile **once** to an intermediate form, then run it on a virtual machine per platform. The compiler's checking with the interpreter's portability.

**Neither.** Both run a wrong answer happily — they check the language's rules, not your intentions.

Two or more devices connected so they can exchange data. That enables sharing hardware and files, communication between people, and reaching central services from anywhere.

A LAN covers one site on cabling the organisation owns, making it fast and cheap. A WAN spans several distant sites over links it does not own — rented lines or the internet — so it is slower and costs more per unit of data.

A personal area network: a few metres around one person, joining a phone to its earbuds or a smartwatch. Usually Bluetooth, chosen for very short range and very low power.

A virtual private network creates an encrypted tunnel across a public network, so a distant device behaves as though it were on the organisation's own LAN and can reach internal servers not exposed to the internet.

Benefit: one central copy of data that everyone works from and that stays current, plus shared hardware. Drawback: a single failure or break-in can affect everyone connected rather than one machine.

The internet is the global network of networks — the connections themselves. The web is one service running on it, made of pages fetched with HTTP. Email, calls and games are other services on the same internet.

Processing data where it is produced rather than sending it away. Right when an answer is needed in milliseconds, when raw data would flood the network, or when the device must keep working if its link fails — smart traffic lights, for example.

Many machines cooperating on one job with no single machine in charge. There is no single point of failure and it scales by adding machines, but keeping every machine agreed on the same answer is genuinely hard. A cryptocurrency blockchain is one.

Benefit: resources available on demand with no hardware to buy or maintain. Limitation: the service depends on both the provider's uptime and your own connection, and the costs recur indefinitely.

Bandwidth is shared with every device nearby, so a busy area slows down, and coverage has gaps where there is no signal from a mast.

A switch moves traffic within one network, delivering each frame to the device it is addressed to; it cannot read IP addresses. A router moves traffic between networks, reading the destination IP address to choose the next hop.

Joins two networks that use different protocols, translating between them so traffic can cross. A plain router only forwards; a gateway also converts.

A modem converts between the network's digital signal and what the physical line carries. A NIC connects one machine to the network. A wireless access point lets devices join the LAN over radio instead of cable.

Network access: switches, network interface cards, wireless access points and modems, handling frames and bits inside one network. Internet: routers and gateways, reading IP addresses to choose routes.

Sits where the network meets the outside world and inspects traffic against its rules, blocking anything forbidden — on outgoing traffic as well as incoming.

An agreed set of rules for a conversation between machines: what gets said, in what order, and what a reply means. Machines from different makers can talk only because both follow the same rules.

TCP numbers packets, checks they all arrived, asks again for missing ones and reorders them — so data arrives complete. UDP sends without checking and never resends, so it is faster but packets may be late, out of order or lost.

When timeliness matters more than completeness — live video, voice calls, online games. A late packet is already useless, so waiting for a resend delays everything after it for no benefit.

Two guarantees: encryption, so nobody between the two ends can read the conversation, and identity, because a digital certificate proves the server really is who it claims to be.

Giving a device an IP address when it joins a network. The device asks, and a DHCP server assigns one from its pool for a limited time, instead of every device being configured by hand.

**Application** (what it means) · **Transport** (did it all arrive) · **Internet** (which host) · **Link** (across this medium).

Each layer **wraps** what it was given in its own header on the way down, and **removes its own** on the way up.

The **MAC address** is rewritten at every hop, because it names only the next device on this link. The **IP address is unchanged** end to end.

**UDP.** TCP would retransmit a lost frame and hold everything behind it — but by then the frame is already in the past, and the pause freezes the call.

Each layer depends only on the **interface** of the one below, so swapping Wi-Fi for Ethernet changes nothing above the link layer.

Reliability, transmission speed, scalability, data collisions and cost. No shape wins on all five, so every recommendation is a trade between them.

Every device connects to one central switch, which makes it cheap, easy to extend and nearly collision-free. Its weakness is that the switch is a single point of failure: if it fails, nothing reaches anything.

Every pair of devices has its own link, so there are many routes and no single link matters. But links grow roughly with the square of the devices — 5 need 10, 20 need 190 — so it is reserved for a few critical points.

Stars joined together, usually by more resilient links between them. Cheap where the devices sit, reliable where the traffic concentrates — which is what almost every real office and campus network looks like.

Because the switch sends each frame only to the device it is addressed to, so devices are never competing for one shared line.

It runs software that **waits for requests and responds**. A **role**, not a kind of hardware — one machine can run several.

**One copy** of the data, permissions and backup in one place, shared powerful hardware, and one update reaching everyone.

A **single point of failure** and a bottleneck — answered by **redundant servers behind a load balancer**.

**Client–server** centralises control and consistency. **Peer-to-peer** has no single failure point and **gets faster as peers join**, but security and consistency are harder.

**Up** — a bigger machine; simple, but has a ceiling and is still one failure point. **Out** — more machines; no ceiling, but the software must allow it.

In client-server one machine holds the data and answers requests from the rest. In peer-to-peer there is no machine in charge — every machine holds a share and serves the others directly.

Benefit: one authoritative copy of the data, with security, access and backups controlled in a single place. Drawback: the server is a single point of failure and can bottleneck when many clients want it at once.

Benefit: no single point of failure, and capacity grows as more peers join, with no expensive server. Drawback: no central control over who sees what, data may disagree between peers, and availability depends on peers being online.

Because an account balance must have one correct value held and controlled by the bank. Copies spread across customers' machines could disagree and none would be authoritative.

By design: every participant holds a copy of the ledger and they agree among themselves what it says, so no single organisation decides what is true.

Splitting one network into smaller separate ones. For performance, because less traffic competes on each segment, and for security, because a break-in or infection is contained where it started.

Dividing the IP address range into smaller ranges, each its own network. Traffic between subnets must pass through a router, which is where rules can be enforced.

A logical grouping of devices configured on the switch, regardless of where each device is plugged in. Two machines in one room can be on different VLANs, and moving someone between groups is a setting rather than re-cabling.

Broadcast traffic reaches only its own segment rather than every device, so on a network split six ways each device sees roughly a sixth as much — the cabling carries useful work instead of noise.

It must be designed and maintained: wrong rules block legitimate work and forgotten rules leave gaps. Each crossing between segments also adds a routing step, and so a little delay.

IPv4 uses 32 bits, written as four numbers, giving about 4 billion addresses — which ran out. IPv6 uses 128 bits, written as groups of hex digits, so the supply is effectively unlimited.

A public address is unique across the whole internet and reachable from anywhere on it, which makes it scarce. A private address is used inside one network only and is not routable on the internet, so millions of networks can reuse the same one.

The router swaps each device's private address for the organisation's one public address on the way out, remembers which device asked, and swaps it back on the reply. It exists because public IPv4 addresses are scarce.

A static address never changes, which anything that must always be findable needs — a web server, for instance. A dynamic address is assigned by DHCP when a device joins and may differ next time, which suits laptops and phones and reuses addresses efficiently.

Private addresses are not routable on the internet, so nothing outside can address an internal machine directly — it can only reply to a conversation that machine started. A firewall is still needed as well.

Twisted pair sends bits as electricity down copper, fibre optic sends them as light down glass, and wireless sends them as radio through the air.

Attenuation is the signal getting weaker with distance — copper fades after about 100 m, fibre runs kilometres. Interference is something else corrupting the signal: electrical noise for copper, walls and other radios for wireless.

Between buildings its very low attenuation and immunity to interference are worth paying for. To a desk the run is short and the bandwidth is never used, so copper's much lower cost wins across hundreds of sockets.

The signal leaves the building, so anyone nearby can receive it, whereas tapping copper or fibre requires physical access to the cable. That is why wireless must always be encrypted.

It is shared with every device nearby, and walls, appliances and other networks all cause interference, so the rate a device actually achieves varies with conditions rather than being fixed.

Data is cut into small packets, each sent independently across the network and joined back together at the destination. No line is reserved for a whole transfer, so many conversations share the network at once.

The destination address, so routers know where to send it; the source address, so a reply or a request to resend can be sent back; and a sequence number saying where this piece belongs in the message.

Each packet is routed independently, and different routes take different times. This is expected behaviour, which is exactly why sequence numbers are in the header.

A switch delivers a frame to the one device it is addressed to within a single network. A router reads the destination IP address and chooses the next network to forward the packet to, one hop at a time.

A reserved line is wasted whenever nobody is talking, and a break in it ends the conversation. Packet switching fills the gaps with other traffic and routes around breaks, and a lost packet means resending one packet rather than everything.

A list held by a router saying, for each destination network, which neighbouring router to forward to. No router knows the whole path — it only ever chooses the next hop.

Routes typed in by an administrator, never changing unless edited. It uses no bandwidth or CPU, behaves completely predictably, has no protocol to go wrong, and cannot be misled by a false routing message.

It does not notice a broken link, so traffic keeps being sent into the fault until someone edits the table by hand. Every change is also manual, so the work grows with the size of the network.

Routers exchange information about what they can reach and build their own tables, adapting automatically when a link fails. It costs bandwidth for the messages, CPU and memory for the tables, and is harder to configure and diagnose.

The time between something changing on the network and every router agreeing on the new routes. During convergence traffic may loop or be dropped, which is the main weakness of dynamic routing.

Sits where the network meets the outside world and inspects every packet crossing it, allowing or dropping each one by rule — on outgoing traffic as well as incoming.

A whitelist allows only what is listed and blocks everything else: safe by default but restrictive. A blacklist blocks only what is listed: convenient, but anything not yet known about gets through, so it is always a step behind.

They stop an already-infected machine sending stolen data out or contacting whoever controls it. Most answers mention only incoming traffic, so this is a reliable extra mark.

Traffic that never crosses it, such as malware on a USB stick or one internal machine infecting another; the contents of encrypted connections, which it cannot read; and attacks delivered over ports the rules legitimately allow.

Internal machines have private addresses that are not routable, so nothing outside can address them directly — only reply to conversations they start. But NAT does nothing about outgoing traffic, what an allowed connection carries, or anything inside the network.

A **vulnerability** is the weakness. An **attack** is someone using it. A **threat** is the person or group who might.

A **virus** needs a user to run the infected file. A **worm** spreads **by itself** across a network, which is why it moves so fast.

**Unencrypted** traffic passing the attacker's machine. Encryption makes what is captured unreadable.

It is **distributed** — traffic arrives from many machines at once, usually ordinary computers that were themselves compromised.

**Urgency defeats caution** and authority is rarely questioned. One person in a thousand clicking is enough, and emailing thousands costs nothing.

Layered controls, so that **one failing does not end the matter** — assume the firewall will eventually be got past.

**Multi-factor authentication.** It turns a stolen password into a failed login, and stolen passwords cause most breaches.

Anything **already inside**, and anything carried over a connection it was configured to **allow** — such as malware in ordinary web traffic.

An untested backup fails when needed, and one reachable from the network can be **encrypted by ransomware along with everything else**.

People **work around** what they cannot follow — writing passwords down, using personal accounts, and not reporting mistakes.

Symmetric uses one key to both lock and unlock — fast, but the key must reach the other end safely. Asymmetric uses two matched keys: a public one anyone may have and a private one that never leaves, so nothing secret has to travel.

For confidentiality, the recipient's public key encrypts and only their matching private key can decrypt. That is why the public key can be handed to anyone without weakening anything.

An organisation's public key together with its identity, signed by a certificate authority the browser already trusts. It proves the public key really belongs to who it claims, which a bare public key cannot.

Asymmetric solves the problem of agreeing a key safely but is slow. So it is used once to agree a symmetric key, and all the actual traffic is then encrypted symmetrically because that is much faster for bulk data.

Keys must be generated properly, stored where nobody else can reach them, replaced periodically and revoked immediately if they leak. A private key that escapes makes every message ever sent with it readable, however strong the algorithm.

A database that stores data in tables and links those tables together with keys, so each fact is stored once in the table it belongs to and other tables point at it rather than copying it.

A primary key uniquely identifies each row in its table. A composite key does that using two or more columns together, when no single column is unique. A foreign key holds a primary key value from another table, which is how the link is made.

Reduced duplication, because each fact is stored once; data integrity, because the database enforces rules such as refusing an invalid foreign key; and consistency, because changing a fact in one place is seen by everyone.

A rigid schema that must be decided up front and is disruptive to change; poor handling of unstructured data such as documents and images; and difficulty scaling very large volumes across many machines.

The same fact gets written out on every row that mentions it. Changing it means finding every copy, and missing one leaves the data contradicting itself.

Conceptual — the entities and relationships the organisation cares about. Logical — those turned into tables, columns, keys and data types. Physical — how the chosen system actually stores it, including files and indexes.

It contains the entities and the relationships between them, in language the organisation recognises. It deliberately omits keys, data types and any choice of database product.

How the chosen system stores the data: files on disk, indexes, partitions and storage settings. This is where performance decisions live, and it must be redone if you change database product.

The schema levels are insulated from each other, so a change at one does not force a change at another. Adding an index at the physical level alters no query written against the logical schema.

So the meaning can be agreed with non-technical people before technical choices are made, so storage can change without breaking programs, and so the same logical design can be built on different database systems.

The entities a database stores and the relationships between them. Each box is one kind of thing that will become a table; each line is a relationship, labelled with the verb joining them.

Cardinality is how many — one or many, drawn as a bar or a crow's foot. Modality is whether the relationship is compulsory — mandatory drawn as a second bar, optional as a circle.

Say it as a sentence in both directions. 'A teacher teaches many classes' and 'a class is taught by one teacher' together give one-to-many, with the crow's foot on the Class end.

A column holds only one value, so neither table can hold several foreign keys. It is replaced by a linking entity with one row per pair, keyed on both foreign keys together.

In the table on the many side. A Class holds TeacherID, because the alternative would need a Teacher row to hold an unknown number of class columns.

It says what kind of value may be stored, and the database refuses anything that does not fit. It also decides what can be done with the values — arithmetic on numbers, true ordering on dates.

Ask whether you will ever calculate with it, compare it, or sort it. If yes it needs a real type; if it is only ever displayed — a phone number or postcode — text is correct however numeric it looks.

A numeric type drops the leading zero, so 07700 becomes 7700, and no arithmetic is ever done on a phone number anyway.

Sorting compares character by character so the order is wrong; date ranges and age calculations become impossible; and nothing rejects an impossible date such as 31/02/2026.

Otherwise the join either fails or silently returns nothing — values that look equal to a person are not equal to the database when their types differ.

Each entity becomes a table and each relationship becomes a foreign key. In a one-to-many the foreign key goes in the many table; a many-to-many needs a linking table holding both foreign keys.

Because a column holds one value. A Class row holds one TeacherID easily, whereas a Teacher row would need an unknown number of columns to hold every class they take.

A composite key uses two or more columns together as the primary key, keeping them separate and queryable. A concatenated key glues values into a single column, such as 2026-S1, which then has to be pulled apart to filter on either part.

Entity integrity: a primary key is never empty or duplicated. Referential integrity: a foreign key must match an existing row. Domain integrity: a value must fit its column's data type.

Rules enforced by the database apply to every program that touches the data, including ones written years later. Rules enforced in a program apply only to that program.

One column's value determining another's. Knowing a StudentID tells you the student's name, so Name is functionally dependent on StudentID. Normal forms are rules about which dependencies are allowed where.

1NF: every cell holds one value and every row is uniquely identified. 2NF: no non-key column depends on only part of a composite key. 3NF: no non-key column determines another non-key column.

A non-key column depending on only part of a composite primary key. With a key of StudentID and Club, StudentName depends on StudentID alone. It can only arise when the key is composite.

A non-key column determining another non-key column. Club determines Teacher and Teacher determines Room, so Room depends on Club only indirectly — which breaks 3NF.

To prevent update problems, where one copy of a repeated fact is changed and others are not; insert problems, where a new club with no members has nowhere to live; and delete problems, where removing the last member loses the club's details too.

List every piece of data with sample rows; make cells atomic and choose the key; move out anything depending on part of a composite key; move out any non-key column determined by another non-key column.

Because functional dependencies are far easier to see in actual data than in a list of column names — repeated values make the repeated facts visible.

In each table ask whether any non-key column determines another non-key column. If so, both move to a new table, and the determining column stays behind as a foreign key.

Pick a fact the scenario needs and follow the keys to find it. If you cannot reach it, a link is missing; if you find it in two places, the design is not yet in 3NF.

More than feels natural — a scenario with eight columns usually becomes about four tables. Finishing with one or two almost always means a transitive dependency was missed.

Deliberately storing some data more than once so that reads need fewer joins and run faster. It is a considered engineering trade, not a mistake.

It gains faster reads and simpler queries. It risks the same fact being stored in two places and disagreeing, requires every update to find every copy, and brings back insert and delete problems.

When data is read far more often than it is written — reports, dashboards and data warehouses that are loaded in bulk and then only read. Never for frequently-written data such as bookings or stock levels.

Keep the normalised tables as the authoritative source and rebuild the denormalised copy from them, so there is always one correct version to fall back on.

Because you should design in 3NF, run it, and find out where it is actually slow. Denormalising before a measured problem exists gives away correctness for a speed gain you cannot demonstrate.

DDL, data definition language, changes the structure of the database — tables, columns, keys. DML, data manipulation language, reads and changes the rows inside tables that already exist. The test is shape versus contents.

CREATE makes a new table with its columns, types and keys; ALTER changes an existing structure, such as adding a column; DROP removes a table entirely, along with everything in it.

SELECT reads rows matching a condition; INSERT INTO adds a new row; UPDATE SET changes values in existing rows; DELETE removes rows from a table.

DELETE removes rows and the table stays, ready for more data — it is DML. DROP removes the table itself, with its structure and all its contents — it is DDL.

DDL is run rarely, by a database administrator, when the design genuinely changes. DML is run constantly, by the application, every time somebody uses the system.

It names the two columns that must match — almost always a foreign key and the primary key it points at. Without it, every row of one table pairs with every row of the other.

FROM and JOIN decide which rows exist, WHERE filters them, GROUP BY collapses them, HAVING filters the groups, SELECT picks the columns, and ORDER BY sorts. SELECT is written first but applied near the end.

WHERE filters individual rows before grouping. HAVING filters groups after grouping, and is the only place a condition on a count or total can go, because that value does not exist until GROUP BY has run.

% stands for any run of characters. 'Sm%' matches anything starting Sm, '%son' anything ending son, and '%ann%' anything containing ann.

When the join can legitimately produce the same row more than once — a student belonging to two clubs would otherwise appear twice in a list of names.

INSERT INTO adds a new row; UPDATE SET changes values in rows that already exist; DELETE removes rows. All three are DML, so the table's structure is untouched.

It applies to every row in the table, with no warning, no confirmation and no undo once committed. The safe habit is to write the WHERE clause first and test it with a SELECT.

It is a separate sorted structure the database can go straight to, instead of reading every row. But every INSERT, UPDATE or DELETE on an indexed column must update that structure as well as the row.

After many changes an index's entries no longer sit in an efficient order, so it gradually stops helping. Reorganising tidies it in place; rebuilding constructs it from scratch. Both are usually scheduled for quiet hours.

With indexes present, every one of the millions of inserted rows updates every index individually. Building each index once at the end is a single sorted pass, which is far cheaper.

**COUNT**, **SUM**, **AVG**, **MIN**, **MAX** — each collapsing many rows into one value.

**WHERE** filters rows **before** grouping. **HAVING** filters groups **after**. A condition on an aggregate can only be HAVING.

**COUNT(*)** counts rows. **COUNT(column)** counts rows where that column is not null — the difference between 1 and 0 after a LEFT JOIN.

**AVG, SUM, MIN and MAX ignore them** — 10 rows with 3 nulls means AVG divides by 7. COUNT(*) is the exception.

Every column in SELECT that is **not inside an aggregate**, or there is no single value to show for the group.

A **stored query with a name**, used like a table. It holds **no data of its own**.

It stores the **query**, not the result, so every read runs it afresh — there is nothing to go stale.

Grant rights on the **view only**. With no permission on the underlying table, a user cannot reach a column the view does not select.

**No.** The underlying query runs on every read. A **materialised view** stores the result and is fast, but is only current to the last refresh.

Sometimes — a simple view over one table often yes. One with a **join, GROUP BY or aggregate** usually not: there is no single underlying row to change.

A group of statements treated as **one indivisible unit** — COMMIT makes them permanent, ROLLBACK undoes them all.

**Atomicity** (all or none), **Consistency** (rules still hold), **Isolation** (no interference), **Durability** (survives a crash).

**Isolation** — achieved by locking the row, so the second transaction waits and then reads the updated balance.

That the change has reached **non-volatile storage** before COMMIT returns — which is why a commit waits for the disc.

Each transaction holds what the other wants, so neither can proceed. The database **aborts one**, which then retries.

**Relational** (tables), **document** (varying fields), **key-value** (fetch by key), **graph** (nodes and edges), **column-family** (columns grouped).

When the **relationships are the question** — "friends of friends" is one traversal against a self-join per level in SQL.

**Query the value.** You fetch by key or not at all, which is why it suits caches and sessions.

**Joins** and enforced schema — so data is duplicated, and update anomalies return.

**No, a trade.** Relational remains right for most business data because it enforces structure and transactions.

**Analysing history** — few enormous reads — as opposed to an operational database recording many small transactions.

**Extract** from each source, **Transform** into one consistent shape, **Load** into the warehouse. Transform is where most of the work is.

So analytical queries **avoid joins**. It is safe because the warehouse is rebuilt in bulk and never edited, so update anomalies cannot arise.

Only as current as the **last load** — often nightly. It never answers "what is happening right now".

**No.** It holds **transformed** data, not the originals, so the business could not be restored from it.

**OLAP** answers a question you already have. **Data mining** finds patterns you did not ask about — one confirms, the other suggests.

**Drill down** to finer detail (year → quarter → month). **Roll up** to a coarser summary (store → region → country).

**Slice** fixes **one** dimension to a single value. **Dice** fixes **several** dimensions to ranges.

**Association** (occur together), **clustering** (groups), **classification** (predict a label), **anomaly detection** (unlike the rest).

Test enough combinations and some look significant **by chance**. It must be validated on data not used to find it — and it is never causation.

**Replication** keeps copies of the same data (availability, read speed). **Fragmentation** splits data between machines (capacity, writes).

**That portion becomes unavailable** — unless the shard is also replicated, which is why real systems do both.

During a network partition you either **refuse to answer** (consistent) or **answer from a reachable copy** (available, possibly stale). You cannot have both.

A bank chooses **consistency** — better to refuse than to allow a double withdrawal. A social feed chooses **availability** — a late post is harmless.

Copies are brought into step **shortly after** a write, not instantly — so a read straight after a write can return the old value.

What the algorithm is given to learn from: labelled examples, unlabelled data, or an environment to act in. Answer that and you have named the type.

Supervised learns from labelled examples to predict the label of something new. Unsupervised is given no labels and finds groups or structure the data already contains — but cannot say what those groups mean.

An agent acts in an environment, receives a reward or penalty for what happens, and over thousands of attempts learns which actions earn the most reward. It needs no dataset, but must be allowed to fail repeatedly.

It uses many layers, each building on what the last found — edges, then shapes, then whole objects — so it works out its own features. The cost is needing a great deal of data and being hard to explain.

Starting from a model already trained on a related task and retraining only its final layers on your own data. It is used when you have too few examples to train from scratch — hundreds rather than millions.

Training repeats the same calculation over millions of examples for hours or days, needing massive parallel processing. Using the trained model is one small calculation per question, which a phone or camera can often do.

Both provide the massive parallel processing training needs. A GPU has thousands of general simple cores; a TPU is a chip designed specifically for machine-learning calculations.

An ASIC is built for one task and can never do another — the fastest and most power-efficient option, but useless if the task changes. An FPGA can be reconfigured after manufacture, so it is slower but adaptable.

When a trained model must answer immediately on the spot — in a camera or a vehicle. It gives millisecond responses, keeps data off the network, and works even when the connection drops.

Training datasets run to terabytes and must be read fast enough to keep the processors busy. Slow storage leaves very expensive hardware sitting idle and waiting.

Finding and fixing what is **missing, duplicated, inconsistent or wrong** before training — because a model learns the faults along with everything else.

Many systems encode "not recorded" as 0. A blood pressure of 0 is impossible, so the model learns from a value that never occurred.

Absence is **rarely random**. If a value is missing more often for one group, deleting those rows removes that group disproportionately.

It counts **twice**, so that record's characteristics carry double weight in what the model learns.

No. An **error** should be; a **genuine extreme** should not — in fraud detection the outliers are exactly the target.

One **input column** the model is given. Feature selection decides which ones it sees.

A feature containing the answer, or one **not available at prediction time**. Test accuracy looks superb and then collapses in production.

It is unique per row, so the model **memorises** rather than learns — perfect on training data, useless on anything new.

**Irrelevant** (no relationship), **redundant** (duplicates another), **constant** (no information), **identifier** (memorises) — and above all **leaking**.

No. Other features **proxy** for it — postcode, school, employment history — and the model finds those instead.

Describing the same data with **fewer features** while keeping as much of the variation as possible.

More features means an **exponentially larger space**, so data becomes sparse, distances lose meaning, and exponentially more records are needed.

**Selection** keeps a subset of the original columns. **Extraction** builds new features from combinations of them, as PCA does.

Finds the directions along which the data varies **most** and uses them as the new axes, so the first few components carry most of the information.

Some **variation** — it is lossy by construction — and with extraction, **interpretability**: a component cannot be named in plain words.

A **continuous** value, by fitting $y = mx + c$ through the data.

By minimising the **sum of squared residuals** — least squares. Squaring stops errors cancelling and punishes large ones heavily.

The change in the predicted value **per unit** of the input — for example price per square metre. It is the interpretable part of the model.

The line continues forever but reality may not. The model has no notion of the range it was trained on and reports **no uncertainty**.

"**How much?**" is regression — a number on a scale. "**Which one?**" is classification — a category.

**Explainability**, speed at prediction, data needed, cost, and **which error is worse** — any of which can outrank accuracy.

If the complicated model barely beats a majority-class guesser or a linear fit, the **complexity is not earning its place**.

Usually **no** — within the variation between cross-validation folds it is noise. Decide on the criteria that genuinely differ.

When a decision must be **justified or audited** — lending, medicine, recruitment. An unexplainable model is then not deployable at any accuracy.

On the **same** training and test data, ideally the same **cross-validation folds**, with the test set opened **once** at the end.

Which **category** something belongs to, learned from labelled examples — binary (two) or multi-class.

**Precision**: of those flagged, how many really were? **Recall**: of the real cases, how many were caught?

A model answering "no" every time scores 99.9% on a 1-in-1,000 condition and finds **nothing**. Ask what a majority guesser would score.

Catches **more real cases** at the cost of **more false alarms** — recall rises, precision falls. It is a human judgement about which error is worse.

Opposite. Spam: a **false positive** (a real email lost) is worse. Screening: a **false negative** (a missed tumour) is worse.

Ask whether it was **chosen before training started**. If the model worked it out from the data, it is a parameter.

How big a step each update takes. **Too high** overshoots the minimum and never settles; **too low** never arrives in the time available.

**Training** learns parameters, **validation** chooses hyperparameters, **test** is opened once to report. Tuning on the test set leaks it.

Splitting into k folds, training on k−1 and testing on the held-out one, rotating — so every record is tested exactly once.

**Grid** tries every combination and is exponentially expensive. **Random** samples within ranges and usually finds something good sooner, because few hyperparameters matter much.

Groups similar records with **no labels** — the groups are the output, which is what makes it unsupervised.

Choose k, place centres at random, **assign** each point to the nearest, **move** each centre to the mean of its members, repeat until stable.

The starting centres are **random** and it finds a **local** optimum, so where it settles depends on where it began.

k-means uses **distance**, so a feature measured in thousands dominates one measured in units — income would decide the clusters entirely.

What the clusters **mean**. It returns "cluster 0, 1, 2"; naming them is a human interpretation that nothing validates.

Items that **occur together**, written {A} → {B}. Unsupervised — nothing is being predicted.

**Support** = both ÷ all baskets. **Confidence** = both ÷ baskets with A. **Lift** = confidence ÷ how often B occurs anyway.

**>1** occur together more than chance (real) · **=1** independent · **<1** less than chance. It is what separates a finding from a popular item.

It rewards whatever is **popular**. 80% confidence is worthless if the consequent appears in 90% of baskets anyway — lift would be 0.89.

**No.** Support is identical, but **confidence differs** — everyone buying caviar buys bread; almost nobody buying bread buys caviar.

Supervised learning is told **the correct answer**. Reinforcement learning is told only **how well things went** — a reward, often long afterwards.

**Agent**, **environment**, **state**, **action**, **reward** — and the **policy**, which maps states to actions and is what is actually learned.

Whether to **exploit** the best action known so far or **explore** another in case it is better. Only exploiting never improves; only exploring never benefits.

Working out **which** of many earlier actions earned a reward that arrived much later — a game won after 200 moves.

The agent maximising **exactly what was measured** rather than what was meant. The system works perfectly; the objective was wrong.

**Population → fitness → selection → crossover → mutation → repeat.**

When the search space is **too large to enumerate**, no formula gives the answer, candidates can be **scored**, and "good enough" is acceptable.

**Mutation.** Crossover only recombines values already in the population; mutation can produce one present in neither parent.

It becomes a **random search** — good solutions are destroyed as fast as they are found.

**No** — a good one. There is no optimality guarantee, and two runs can give different answers.

Each input **times a weight**, summed, **plus a bias**, passed through an **activation function**.

**Input** (one unit per feature), **hidden** (where the work happens), **output** (one unit per class).

Without it, stacked layers collapse into a **single weighted sum** — a hundred layers would have the power of one.

Working **backwards** from the error to find each weight's contribution, so every weight can be nudged in the direction that reduces it.

It changes the **weights and biases**. The number of layers, units and the activation function are **hyperparameters**, fixed beforehand.

Slides a small **filter** of weights across the input, multiplying and summing at each position to produce a **feature map** of where that pattern occurs.

The **same** filter is used at every position, so a feature is recognised **wherever it appears** — and one detector costs a handful of weights rather than a set per location.

Keeping the strongest value in each block: **fewer numbers** to carry forward, and tolerance to small shifts in position.

**Edges**, then shapes built from edges, then objects built from shapes — a hierarchy that is learned rather than designed.

It **destroys the geometry** — the network no longer knows which pixels were adjacent — and a 200×200 colour image gives 120,000 inputs, needing millions of weights.

From training data that reflects the world as it was. A model learns the patterns in past decisions, so historical unfairness is reproduced at scale — and wearing the appearance of objectivity, which makes it harder to challenge.

Because other fields stand in for it — a postcode can imply background, a school can imply income — and the model finds those substitutes on its own.

A model can be 95% accurate overall and far worse for a small group, because that group barely affects the average. The headline number hides exactly the problem you are looking for.

When a model causes harm it is unclear who answers for it — the developer, the organisation using it, or the operator. 'The system decided' gives the affected person nobody to appeal to.

Transparency, since a complex model cannot easily explain its decision; privacy and consent, because data given for one purpose is used to train models; and environmental impact, since training large models uses very large amounts of energy and water.

Because they were written for the technology that existed at the time. Something genuinely new does not break the old rules — it sits outside them, doing something nobody thought to allow or forbid.

Individual rights: can a person refuse, and appeal? Privacy: what is collected, and did bystanders agree? Equity: who is left out or served worse? Society: what changes when everyone has it?

It would eventually break much of today's encryption. Because encrypted data can be stolen and stored now and decrypted later, the risk begins before the machines exist — so organisations need quantum-resistant encryption already.

The glasses go everywhere the wearer goes, recording everyone they meet without any consent, and they can also alter what the wearer sees — which raises the question of who chooses that.

Because of the accumulation. When jobs, loans, healthcare and policing all involve models, large parts of a person's life are decided by systems they cannot see, question or appeal against.

Problem statement, objectives and goals, input specification, output specification, constraints and limitations, and evaluation criteria.

You can describe the test that would settle it in one sentence. 'Return results in under five seconds on 10,000 records' can be tried; 'be fast' is an opinion and never can be.

Each input item, its data type, its valid range, and where it comes from — for example 'Member ID: a whole number between 1 and 99999, entered by staff'. The validation rules come straight from this.

What happens when there is nothing to show. Stating 'a message if there are no results' is a cheap and reliable mark.

So the target cannot be moved afterwards. Deciding what counts as success once you already know what you built is not judging the work at all.

Decomposition — breaking a large problem into smaller separate ones. Pattern recognition — finding what repeats. Abstraction — deciding what to leave out. Algorithmic design — writing the steps precisely.

Deciding what to leave out, and why — not being vague. A route-planning app treats a road as a start point, an end point and a travel time, dropping surface, width and street name as irrelevant.

Finding the parts of a problem that are the same, so one solution serves many cases. Every track event needs the same steps, so solving it once covers the 100 m, the 200 m and the relay.

Setting out the steps in order, precisely enough that someone else could follow them without asking a question. It does not require code — plain steps or a flowchart are enough.

No. The guide states it explicitly: it is a toolkit of problem-solving techniques. Planning a sports day, designing a database and diagnosing a fault all use the same four.

What are the pieces (decomposition)? What repeats (pattern recognition)? What can I ignore (abstraction)? What are the steps (algorithmic design)? Then trace the steps on a small example by hand.

Decomposition splits one wide table into several; abstraction decides which attributes each entity actually needs; pattern recognition notices that every many-to-many relationship needs a linking table.

In choosing which features to give the model and which to leave out. It is usually the single most important decision in a machine-learning project.

Because it turns a plausible-looking algorithm into one you know is right, and it finds the error before any code exists to debug. It is also very often exactly what the exam asks for.

To test whether you can take a problem described in words and make it solvable without reaching for a programming language — which is what computational thinking means.

Rounded box for Start/End, slanted box for Input/Output, rectangle for Process, diamond for Decision with two labelled exits, arrow for Flowline, and a small circle for Connector.

There is no loop symbol. A loop is a decision diamond with a flowline going back up to it — follow the arrows and the loop is obvious.

Draw the table first with one column per variable plus output; write a new row for every change; write the comparison out in full at every diamond; and add to the output column only when an output box is reached.

The boundary case. When the test is 'count at most N', the loop still runs when the two values are equal — one more time than most people expect.

Exactly two, labelled Yes and No. A diamond drawn with one exit or with three is drawn incorrectly.

A named place in memory holding one value. Its data type says what kind of value it is, which decides both what can be stored there and what operations work on it.

Integer: a whole number. Decimal: a number with a fractional part. Char: a single character. String: a sequence of characters. Boolean: exactly True or False.

It adds numbers and joins strings, so 12 + 1 gives 13 but "12" + "1" gives "121". Mixing the two — "12" + 1 — fails, and is one of the commonest bugs.

A local variable is created inside a function, cannot be seen from outside, and is destroyed when the function ends. A global variable is created outside any function and is visible throughout the program.

If a local value is wrong, the cause is inside that function. If a global value is wrong, any part of the program could have changed it — so the bug could be anywhere.

Positions start at 0, and a slice excludes its end position. So text[2:5] gives the characters at 2, 3 and 4 — three characters, which is simply 5 minus 2.

len gives the number of characters. find gives the position where a piece of text starts, or -1 if it is absent. split breaks a string into a list at each occurrence of a separator.

No. upper, lower and replace all return a new string and leave the original untouched. To keep the change you must assign it back: text = text.upper().

Find the position of the @, then take everything before it and everything from one position after it: at = email.find("@"); user = email[:at]; domain = email[at + 1:]. The +1 skips the @ itself.

Whenever the parts can vary in length. code[0:2] works only while the prefix is exactly two characters, whereas splitting at the separator survives a longer or shorter one.

A problem that appears while the program is running, rather than a mistake in the code's grammar. Without handling the program simply stops; with handling it can report the problem and carry on.

try holds only the lines that might fail. except (catch in Java) handles one specific kind of failure. finally runs whether or not anything failed, and is where files get closed.

Unexpected input, usually from people; unavailable resources such as a missing file or unresponsive network; and logic errors, where the code ran on values nobody planned for.

When the problem is predictable and inside your control — an empty list, a zero divisor. Catch the things outside it: files, networks and databases, which can fail between your check and your use.

If a line inside try fails, control jumps straight to except and any later lines in try never run. finally runs either way, so the file is closed rather than left open holding a system resource.

Syntax errors stop the program running at all. Run-time errors stop it partway with a message. Logic errors let it run perfectly and produce the wrong answer — and only the third needs debugging.

Trace table: work through by hand, no tools needed — the exam method. Print statements: show a value at a chosen point. Breakpoints: pause and inspect every variable. Step-by-step execution: run one line at a time and watch values change.

Write down what you expected for one specific input; find the first value that is wrong, halving the search each time; look only at the lines that set that value; then change one thing and test again.

At the boundary: an empty list, a single item, the first and last positions, and values that are exactly equal. If a program is wrong, test the boundary before anything else.

If the change works, you know which change fixed it. If it does not, you have not added a new set of suspects to investigate.

A static structure has its size fixed when it is created, in one contiguous block of memory. A dynamic structure grows and shrinks while the program runs, taking more memory only when it needs it.

Everything sits in one block with items of equal size, so the address of item 20 is simply the start plus twenty item-widths. It is one calculation, with nothing searched for — O(1).

When it outgrows its block it must claim a bigger one and copy everything across. That single operation is expensive, but it happens rarely, so the average cost of adding an item stays low.

When the size is genuinely fixed — twelve months, seven days, sixty-four squares — or when a very large amount of data is scanned repeatedly and both speed and predictable memory matter.

You must guess a maximum. Guess too small and it overflows or silently discards data; guess too large and most of the memory is never used — with still no guarantee the guess was enough.

By position, starting at 0. A list of four items has positions 0, 1, 2 and 3, so asking for position 4 is an error — the commonest list bug there is.

append adds at the end, insert(position, value) adds anywhere and shifts the rest along. remove(value) takes out the first match, and pop() removes the last item and gives it back.

Removing shifts everything after it down one place while the loop counter moves up, so items get skipped silently. Build a new list instead, or loop over a copy.

A list whose items are themselves lists — a grid. It is addressed [row][column], always in that order: grid[1][2] is row 1, column 2.

The outer loop gives you each row, which is itself a list; the inner loop reaches the individual values inside it. That is also why scanning a grid is O(rows × columns).

A structure that allows adding and removing at one end only, the top. The last item put in is the first taken out — last in, first out, or LIFO.

push adds an item on top; pop removes the top item and returns it; peek returns the top item without removing it; isEmpty says whether there is anything in the stack at all.

Every operation touches only the top. Nothing is shifted along and nothing is searched for, so the cost is the same whether the stack holds three items or three million.

Undo, where the most recent action must be reversed first; the call stack, since function calls unwind in reverse order; and checking that brackets match, because the most recent opening bracket must close first.

A stack that keeps growing with nothing being popped until it runs out of memory — usually a function that calls itself with no way to stop.

A structure added to at one end and taken from at the other: items join at the back and leave from the front. The first item in is the first out — first in, first out, or FIFO.

enqueue adds an item at the back; dequeue removes the item at the front and returns it; front returns the next item out without removing it; isEmpty says whether anyone is waiting.

Removing from the front of a list shifts every remaining item down one place, which is O(n) every time. A proper queue structure removes from the front in constant time.

Does the most recent item matter most, or the one that has waited longest? Most recent means a stack; longest waiting means a queue.

Print jobs, so they print in the order sent; process scheduling, where round robin takes the front process and returns it to the back; and buffering data such as keystrokes or network packets, which must be handled in arrival order.

Both lines are perfectly valid, so nothing is reported. The program runs to completion and simply produces the wrong answer.

The thing the loop's test depends on never changes — most often because the counter is increased inside a branch that does not always run, so the test can never become false.

Set up before the loop — totals at 0, counters at their start. Do the work for one item inside. Print or return the finished result after, since printing inside shows a running value rather than the final one.

Two parts of a program each hold a resource the other is waiting for, so neither can move. It is prevented by having every part claim shared resources in the same fixed order.

Is every value set before it is used? Does the thing the loop tests always change? Is the result used after it is complete rather than during? Those three catch nearly every sequence error.

A chain runs exactly one branch and skips the rest once a match is found. Separate ifs test every condition, so several may run or none. Use a chain for mutually exclusive cases and separate ifs for independent ones.

The chain stops at the first true test. If mark >= 50 is tested before mark >= 70, every mark of 70 or more matches the first test, so the later branch is unreachable.

and requires both sides to be true; or requires at least one; not reverses the result. They are the same logic as the AND, OR and NOT gates, with the same truth tables.

The second half is a bare piece of text rather than a comparison, and non-empty text counts as true — so the whole condition is always true. Each side of an or must be a full comparison.

== compares two values and produces a Boolean; = assigns a value to a variable. Writing = where == belongs is a classic error.

Ask whether you know how many times it must repeat before it starts. Yes means a counted loop (for); no means a conditional one (while), which repeats as long as a condition holds.

Five times, taking 0, 1, 2, 3 and 4. It starts at 0 and stops before 5 — the same rule as a string slice, and the same source of off-by-one errors.

Yes. The condition is tested before the first pass, so if it is already false the body never runs at all. That is correct behaviour and often exactly what is wanted.

Before the loop. Setting it inside resets it on every pass, so the final answer would be just the last value rather than the accumulated one.

The inner loop runs completely for every single pass of the outer loop, so the total work is rows times columns. That is where quadratic complexity comes from.

A named block of code that does one job, is given data through parameters, and hands back a result with return. Written once, it can be called anywhere and fixed in one place.

The parameter is the name in the function's definition — the placeholder. The argument is the actual value supplied when the function is called.

Reusable: one definition serves every caller. Maintainable: a fix applies everywhere at once and faults trace to one function. Testable: each function can be tested on its own. And work can be split between people.

A function told what it needs works anywhere, can be tested on its own, and cannot be broken by something changing elsewhere in the program.

A returned value can be stored, compared or displayed by the caller, and the function can be tested. A function that only prints can do none of those.

How an algorithm's work grows as the data grows — the shape of the growth, not the time in seconds, which depends on the machine it runs on.

Count the loops over the data. No loop is O(1), one loop is O(n), a loop inside a loop is O(n²), and halving what is left at each step is O(log n).

Big O describes the shape of the growth, and constants and lower-order terms do not change that shape. Doubling the data still doubles the work.

Time complexity is how the number of steps grows; space complexity is how the extra memory grows, not counting the input. Bubble sort is O(n²) time but O(1) space, because it sorts in place.

Twice the data means four times the work, and ten times the data means a hundred times. At 1,000 items that is a million steps; at 10,000 it is a hundred million.

It checks each item in turn until it finds the target or runs out, returning the position or -1. Best case O(1) if the target is first, worst case O(n) if it is last or absent.

Look at the middle item. If it equals the target, stop. If it is too small the target is to the right, so move low to mid + 1; if too big, move high to mid - 1. Each step discards about half the remaining list.

Discarding half depends on knowing which half the target would be in, which only holds if the list is in order. On unsorted data it does not run slowly — it returns the wrong answer.

When low passes high, meaning there is nothing left to search. It then returns -1 to indicate the target is absent.

Doubling the list doubles linear search's worst case, but adds only one comparison to binary search's. Sixteen items need at most four binary comparisons; a million need about twenty.

It compares each neighbouring pair and swaps any that are out of order. Each pass sends the largest remaining value to the end, so the next pass can compare one fewer pair.

For each position it looks through the whole remaining list, remembering where the smallest value is, then swaps it into place. At most one swap per position.

Both make O(n²) comparisons. Bubble sort makes up to O(n²) swaps; selection sort makes only O(n). Bubble sort has a best case of O(n) on sorted data thanks to its early exit, while selection sort has none.

Both are O(1). Each sorts in place, needing only a couple of extra variables however large the list becomes.

When writing data is far more expensive than reading it. The comparison counts are identical, so the algorithm doing O(n) swaps instead of O(n²) is clearly better.

A **base case** that returns without recursing, and a **recursive case** that calls itself on a smaller problem.

Each call keeps a **stack frame** — parameters, locals, return address — and none is released until the base case is reached.

They return in the **reverse order** they were made, most recent first — last in, first out.

When the **data is self-similar** — a tree, a folder structure, a nested expression. Iterating those needs an explicit stack managed by hand.

It is a good **teaching example**, not a good choice — a loop is faster and uses constant memory.

**Down** — each call is made and waits, with no arithmetic. **Up** — each returns a value, and the arithmetic happens.

On the way **up**, once the base case has returned a value to add to. Nothing is computed descending.

Indent each call **one level further** than its caller; leave the return blank going down and fill it in coming back up.

The calls form a **tree**, the left branch completes before the right, and the same values are computed repeatedly.

Calls grow **exponentially** — fib(30) makes over 1.3 million — because nothing is remembered between branches and sub-results are recomputed.

r reads and fails if the file does not exist. w empties the file immediately and then writes, creating it if absent. a appends at the end, keeping what was already there.

It empties the file the moment it opens, before anything is written. Choosing w when you meant a destroys the previous contents, and no error is raised because it is a valid operation.

Every line carries the invisible newline that ended it, so comparisons fail until it is stripped. And everything read is text, so "72" must be converted with int() before any arithmetic.

Its contents may not be fully written to disk otherwise, and an open file holds a system resource, possibly locking it against other programs.

It closes the file automatically when the block ends, even if something fails inside it. It is the finally block of exception handling, built into the language.

An approach that keeps a thing's data and the operations on it in one place. A book's title and its borrow() method live together, rather than the data in one structure and the code elsewhere.

A class is the template, saying what every one of this kind will have and can do; it holds no values itself. An object is one actual thing made from that class, with its own values.

Inheritance is reusing what a more general class already has — Ebook takes Book's title and author. Polymorphism is the same method call answered appropriately by each kind. Inheritance often makes polymorphism possible, but they are different ideas.

Advantages: it models real things with data and behaviour, and inheritance gives reuse with no copied code. Disadvantages: the class structure must be designed before coding, and it is more code than a small task needs.

For a short script with no real entities to model — reading a file and printing a total gains nothing from classes while still paying the design and code overhead.

Underline the nouns as candidates for classes and attributes, and the verbs as candidates for methods. It is crude but gets a first draft right surprisingly often.

The name at the top, the attributes in the middle with their types, and the methods at the bottom with their return types — always in that order.

A minus sign means private, reachable only inside the class. A plus sign means public. An underlined entry is static, belonging to the class itself rather than to each object.

In the class that holds the data it uses. borrow() belongs on Book because Book holds onLoan; putting it elsewhere would force that attribute to be made public, losing encapsulation.

When the relationship is really 'has a' rather than 'is a'. A Library has Books but is not a Book, so it should hold a collection rather than inherit.

A non-static (instance) variable has one copy per object, holding what makes that object different. A static (class) variable has exactly one copy belonging to the class itself, shared by every object.

Because it is a fact about the class, not about any one object. As an instance variable, every object would hold its own count of 1 rather than a shared running total.

An instance method uses the object's own data and cannot be called without an object. A static method belongs to the class, uses no object's data, and can be called as Book.count() with no object at all.

It can be called with no object in existence, so there is nothing for self to refer to — no way to know which object's data was meant.

Would every object have the same value, always? Yes means static; no means it must be an instance variable. In doubt, choose instance — sharing one value is a decision, not a default.

Defining writes the template once, saying what every one will have and can do. Instantiating creates an actual object from that template, with its own values, as often as needed.

It runs automatically when an object is created and gives every attribute a value, so no object ever exists in an unfinished state. It can also refuse invalid values before the object exists.

The object the method was called on. self.title is this particular book's title, which is what lets one method definition serve every object of the class.

Some have a single correct starting value. A new book is never on loan, so onLoan is set to False inside the constructor rather than asked for — which removes a chance to get it wrong.

The object exists with a missing value, and the failure appears much later, somewhere that has nothing to do with the cause — which makes it hard to trace.

Keeping an object's data private and providing public methods as the only way to reach it, so every change goes through code that can check it first rather than any part of the program writing whatever it likes.

Encapsulation is the mechanism — private attributes, public methods. Information hiding is the principle behind it: the outside should know what a class does, not how, so the inside can be rewritten without breaking callers.

A getter returns a private value; a setter changes one after checking it. Providing a getter but no setter makes a value readable from outside but not changeable.

The data is then effectively public with extra typing. The value of encapsulation lies in the checking that happens on the way in, not in the wrapping itself.

The fault must be inside that class, since nothing outside could have written it. With a public attribute, any line of the whole program could be responsible — the same argument as preferring local variables to global ones.

Defining a class as a **specialised version** of another, taking its attributes and methods and adding its own.

Say it aloud. "A SavingsAccount **is an** Account" → inheritance. "A Car **has an** Engine" → composition.

Calls the **parent's** version — usually the constructor, which sets the inherited attributes. Without it those attributes are never set.

A child class **redefining** a parent's method. Its version is used for objects of that class only.

A child depends on the parent's **internals**, not just its interface, so one change to the parent can break every subclass at once.

The **same call** behaving differently depending on the object it is made on — the caller never asks what type it holds.

**Overloading** — resolved at compile time. Overriding is a child replacing a parent's method, resolved at run time.

A type-checking **if-chain**, repeated everywhere the objects are handled — and every copy is a place to forget a type.

**Nothing** — it works with existing loops immediately, so no working code is edited and nothing can break.

No. Inheritance **shares** a method; polymorphism is the same call **resolving differently** per object. Inheritance is usually how it is achieved.

Exposing only the operations a caller needs and **hiding how they are done**.

**Abstraction** decides *what* is exposed (design). **Encapsulation** enforces *how* it is protected (access control).

Its abstract methods have **no bodies**, so an object of it could be asked to run a method that does not exist.

**Abstract class** when children share real behaviour and attributes. **Interface** when unrelated classes must offer the same operations.

One where the caller must know **how** it works to use it correctly — saveToMySQL() rather than save().

Both are has-a. **Composition** owns the part, which dies with the whole. **Aggregation** references a part that exists independently.

Delete the whole. If the part still makes sense it is **aggregation**; if it is meaningless it is **composition**.

The whole **creating** the part inside itself → composition. The part **passed in** → aggregation.

The **filled** diamond ◆. A hollow diamond ◇ means aggregation.

Looser coupling (interface, not internals), parts swappable at run time, and none of the parent's unwanted members.

A **named, reusable solution** to a recurring problem — a description of a structure and why it works, not a library.

Objects **subscribe** to a subject and are notified when it changes. The subject never knows who is listening.

Putting the decision of **which subclass to create** in one place, so concrete class names are not scattered through the code.

Interchangeable algorithms behind one interface, **selected at run time** — replacing an if-chain that chooses behaviour.

It is **global state**: testing becomes hard and the parts of the program that depend on it are hidden.

The **operations** available and what they mean — not how the data is stored.

**ADT.** It promises push, pop, peek and last-in-first-out order. An array or a linked list is how you build one.

So it can be **replaced** without changing any calling code, because callers only ever depended on the operations.

A **set** — duplicates cannot be stored, so the structure guarantees it rather than the programmer remembering to check.

By the operation the program performs **most**, with its complexity — and what the alternative would cost.

A **value** and a **reference to the next node**. Nothing else, and no node needs to sit beside another in memory.

There is no calculation that locates a node — you must start at the head and **follow every reference** in turn.

**Singly** points forwards only. **Doubly** points both ways, at the cost of a second reference per node. **Circular** links the last node back to the first, so there is no null end.

It gives up **direct access** (O(n) to reach position n) and gains **cheap insertion and deletion** (O(1) once in position), plus a size that grows and shrinks.

Array elements are **contiguous**, so reading one pulls its neighbours into cache. Linked-list nodes are scattered, so each hop risks a cache miss.

A **Node** holding a value and a reference to the next, and a **head** reference pointing at the first node.

**Point the new node forwards first** (new.next ← prev.next), then repoint the previous node (prev.next ← new). The other order overwrites the only reference to the rest of the list.

By **routing around it**: prev.next ← target.next. Nothing is erased — the node simply becomes unreachable.

There is no previous node to reroute, so the head itself moves: head = head.next.

When current returns to the **head**. There is no None to test for.

For **every** node, all values in its left subtree are smaller and all in its right subtree are larger — every descendant, not just the children.

Each comparison says which side the value must be on, so an **entire subtree** is discarded without being examined. About log₂ n comparisons when balanced.

Every value in **ascending order** — left subtree, node, right subtree — with no sorting step.

Every value goes the same direction, so the tree **degenerates into a line**: height n, search O(n), exactly like a linked list.

It is replaced by its **in-order successor** — the smallest value in its right subtree — which preserves the ordering rule.

**No duplicates** and **no order** — both enforced by the structure rather than by the programmer.

**Union** everything in either · **intersection** only what is in both · **difference** in the first and not the second.

**No.** With a = {1,2,3} and b = {3,4}: a − b = {1,2} but b − a = {4}. Difference is the one operation whose order matters.

The value itself computes where it would be stored, so nothing is searched for. A list must compare against every element — O(n).

When the program needs **position or order** — a set has neither, and no index to ask with.

It runs the key through a **hash function**, takes the result **modulo the table size**, and goes straight to that bucket. The address is computed, not searched for.

**Deterministic** (same key, same bucket, always), **fast** (it runs on every operation) and **uniform** (keys spread evenly).

There are more possible keys than buckets, so two keys must eventually map to the same one. It is a counting argument, not a defect.

**Chaining** stores colliding keys in a list inside the bucket. **Open addressing** puts them in the next free bucket, so the table can never hold more items than buckets.

**O(1) on average, O(n) in the worst case** — the worst case being a hash function that clusters every key into one bucket.