Thinking in algorithms

Why this matters

An algorithmA precise, ordered, finite list of steps that solves a problem. is a precise, ordered list of steps that solves a problem. Algorithms are not only for programmers. A lockout procedure, a troubleshooting flowchart, a lab protocol and a recipe are all algorithms. Learning to think in algorithms means learning to break a messy task into small steps that are clear enough for someone else (or a computer) to follow, and that you can test one at a time.

Computational thinking

Computer scientists describe four habits that make problems easier to solve:

1. DecompositionBreaking a big problem into smaller parts that you can solve one at a time.: break a big problem into smaller parts. "Analyse the test results" becomes: load the data, remove bad readings, calculate averages, compare with the limit, write the summary.
2. Pattern recognition: notice what is similar. If every sensor file has the same layout, one method can process all of them.
3. AbstractionIgnoring the details that do not matter for the task so you can focus on the ones that do.: ignore details that do not matter for the task. To plan a delivery route you need distances, not the colour of each building.
4. Algorithm design: write the exact steps, in order, including what to do in each situation.

What makes a good algorithm

A good algorithm is:

• Precise: each step has one meaning. "Add some water" is not precise; "add 250 mL of water" is.
• Ordered: steps happen in a defined sequence.
• Finite: it always finishes.
• Correct for every case, including the awkward ones: an empty list, a negative number, a tie.

Worked example: finding the largest value

Task: find the highest temperature in a list of readings. How would you do it on paper, one number at a time?

1. Look at the first reading and remember it as "the largest so far".
2. Look at the next reading.
3. If it is bigger than the largest so far, remember it instead.
4. Repeat steps 2 and 3 until there are no readings left.
5. The value you are remembering is the answer.

Trace it by hand on [3, 9, 2, 7]:

Answer: 9. Now test the awkward cases. Does it work if all the numbers are negative, such as [-5, -2, -8]? Yes, because we started with the first reading instead of zero. If we had started with zero, the answer would wrongly be 0. Testing edge cases like this is how you find bugs before they matter.

In JavaScript, the same algorithm looks like this:

function findLargest(numbers) {
  let largest = numbers[0];        // step 1
  for (const n of numbers) {        // steps 2 and 4
    if (n > largest) {              // step 3
      largest = n;
    }
  }
  return largest;                   // step 5
}

Each line maps directly to a step you wrote in plain English. That is the point: write the steps first, then the code.

Flowcharts and pseudocode

Two tools help you design algorithms before writing any code:

• PseudocodePlain-language steps with a little structure (for each, if, otherwise), written before real code.: plain-language steps with a bit of structure ("for each reading... if... otherwise..."), like the numbered list above.
• Flowcharts: boxes for actions, diamonds for yes/no decisions, arrows for the order. Troubleshooting guides in trades and IT are often flowcharts.

Testable steps

Each step should have an outcome you can check. "Clean the data" is hard to test. "Remove any reading below -50 °C or above 150 °C, because those are outside the sensor's range" can be tested with a few example values. When something goes wrong, testable steps let you find which step failed, instead of starting again from scratch.

Efficiency, briefly

Different algorithms for the same task can take very different amounts of time. Finding a name in a sorted list by checking every entry might take 1,000 steps; repeatedly halving the list (like finding a word in a dictionary) takes about 10. You will meet this idea, called algorithmic complexity, in later courses.

Common mistakes

• Steps that are too vague for someone else to follow.
• Forgetting edge cases: empty inputs, negatives, ties, the first and last items.
• Starting with code before you understand the steps.
• Never tracing by hand. A quick table on paper finds most logic errors.

Quick recap

• An algorithm is a precise, ordered, finite set of steps.
• Decompose, look for patterns, abstract away noise, then write the steps.
• Trace by hand and test edge cases.
• Write steps in plain language first, then translate each one into code.

Try it

Open the Do tab. The findLargest function from this lesson is missing its comparison. You will write that one condition, and the checks will test it on normal and edge cases.