Welcome to the World of Algorithms!
In this chapter, we are going to explore the "blueprints" of computer science. Think of an algorithm as a recipe: before you can bake a cake, you need a clear list of steps to follow. In the same way, before a computer can run a program, it needs a clear set of instructions. Don't worry if this seems a bit abstract right now—we’ll break it down piece by piece!
What you will learn:
• How to define and explain algorithms.
• How to break big problems into small pieces (Decomposition).
• How to ignore things that don't matter (Abstraction).
• How to represent these steps using flowcharts and pseudo-code.
• How to check if an algorithm actually works using trace tables.
1. What is an Algorithm?
At its simplest, an algorithm is a sequence of steps that can be followed to complete a task. Whether you are tying your shoelaces or calculating the square root of a number, you are following an algorithm.
Important Distinction:
An algorithm is the plan, while a computer program is the action. Think of an architect’s blueprint versus the actual house. The blueprint is the algorithm; the house is the program.
Analogy: If you tell a friend how to make a cup of tea, you’ve given them an algorithm. If they actually go into the kitchen and make it, they are "executing" that algorithm.
Quick Review: An algorithm is a set of instructions; a program is those instructions written in code for a computer to run.
2. Breaking it Down: Decomposition
Sometimes, a problem is so big it feels impossible. Decomposition is the process of breaking a complex problem down into smaller, more manageable parts (sub-problems).
Each of these sub-problems should accomplish a specific task. You can even break those sub-problems down further!
Example: If your problem is "Organize a Birthday Party," you can decompose it into:
1. Create a guest list.
2. Buy snacks.
3. Send invitations.
4. Clean the house.
Key Takeaway: Breaking a big job into small jobs makes it much easier to solve!
3. Simplifying the View: Abstraction
Abstraction is the process of removing unnecessary detail from a problem so you can focus on the important parts. If you include too much detail, the algorithm becomes confusing.
Example: Think of a map of the London Underground. It doesn’t show every twist and turn in the tracks or where the trees are above ground. It only shows the stations and the lines. That is abstraction—it removes the "clutter" so you can find your way.
Did you know? Without abstraction, video games would be impossible to play! Developers hide the millions of complex math equations happening in the background and only show you the character moving on the screen.
4. Representing Algorithms
Once you have a plan, you need to write it down so others (and computers) can understand it. There are three main ways to do this:
A. Flowcharts
These are visual diagrams using different shapes to show the flow of the algorithm. Common shapes include:
• Ovals: Start or End.
• Rectangles: A process (like a calculation).
• Diamonds: A decision (Yes/No questions).
• Parallelograms: Input or Output.
B. Pseudo-code
This is a way of writing instructions that looks a bit like programming code but is easier for humans to read. It doesn't have strict rules like "Python" or "C#", but AQA uses a standard version in exams.
Example of Pseudo-code:
OUTPUT 'Enter your age'
USERINPUT age
IF age >= 18 THEN
OUTPUT 'You can vote!'
ELSE
OUTPUT 'Too young to vote.'
ENDIF
C. Program Code
This is the final version written in a specific language like Python, C#, or VB.NET that the computer can actually execute.
Memory Aid: Use FPP to remember the three ways: Flowchart, Pseudo-code, Program code.
5. Inputs, Processing, and Outputs (IPO)
Every simple algorithm can be explained using these three stages:
1. Inputs: The data that goes into the algorithm (e.g., typing your name).
2. Processing: The steps taken to change or use that data (e.g., adding two numbers together).
3. Outputs: The result that comes out (e.g., displaying a total on the screen).
Analogy: A vending machine.
• Input: You press the button for "Cola" and insert money.
• Processing: The machine checks if you gave enough money and locates the drink.
• Output: The drink falls into the tray.
Quick Review: Look at any algorithm and ask: What is it asking for? What is it doing? What is it showing?
6. Determining the Purpose: Trace Tables
How do we know if an algorithm works? We use a trace table. This is a technique used to test an algorithm by manually recording the value of variables at each step. This is often called a "dry run".
Step-by-Step for Trace Tables:
1. Create columns for each variable in the algorithm.
2. Follow the instructions line by line.
3. Every time a variable changes, write the new value in the next row of the table.
Common Mistake to Avoid: Don't skip lines! Even if you think you know what the answer will be, following the algorithm line by line is the only way to catch "logic errors" (mistakes in the plan).
Key Takeaway: Trace tables help you "think like a computer" to see exactly what the algorithm is doing at every moment.
Final Summary: The Algorithm Toolkit
• Algorithm: A step-by-step plan.
• Decomposition: Break it down into pieces.
• Abstraction: Hide the details that don't matter.
• Pseudo-code/Flowcharts: Ways to draw or write the plan.
• Trace Tables: Checking the plan to make sure it works.
Keep practicing! Algorithms are just logic puzzles. The more you "trace" them, the easier they become to understand.