Module 4 · Lesson 4.1
The vocabulary, and what each idea buys
Algorithm, variable, condition, loop, function, data structure — the six ideas an engineer needs, and what each one is for.
Why this matters
This is not a programming course, and it does not need to be. An engineer needs enough to automate a repetitive check safely, read a colleague's script, and judge whether a tool that came from somewhere else can be trusted.
Six ideas cover most of that. What follows treats each as an engineering tool with a purpose, rather than as syntax.
The six
Algorithm. A sequence of unambiguous steps that turns an input into an output. The difficulty is never the sequence; it is the unambiguity. 'Check the beam' is not an algorithm. 'For each load combination, compute the moment; find the section whose moment resistance exceeds it and whose deflection under the serviceability combination is below span/360; return the lightest' is.
Variable and parameter. A named value. Naming it is the point: span rather than 7.2 means the number appears once, and changing it changes every use. The alternative — the same number typed in eleven places — is the single most common source of silent error in engineering calculation, in any medium.
Condition. A branch: if the utilisation exceeds one, then take the next section. Conditions are where the engineering judgement gets encoded, and they are where the untested edge cases live. What happens exactly at 1.0? What if the list runs out?
Loop. Repetition. Loops are what make automation worth doing and they are also how one mistake becomes two hundred. A loop over load cases applies your logic — and your error — to every case identically.
Function. A named, reusable piece of behaviour with declared inputs and outputs. This is the unit of reuse, of testing, and of understanding. A function that computes a moment resistance can be tested against a worked example independently of everything around it, and that is what makes the whole assembly trustworthy.
Data structure. How information is organised. A list of load cases, a table of sections, a nested description of a frame. Choosing it badly makes everything downstream awkward; choosing it well makes the code read like the engineering.
Error handling and testing
Two more that are not optional in engineering software.
Error handling. What happens when the input is nonsense — a negative span, an empty section list, a load case with no loads. The right behaviour is nearly always to stop and say so. A tool that returns a plausible number for impossible input is more dangerous than one that crashes, because the crash gets investigated.
Testing. A test is a worked example the computer re-checks every time the code changes. Its value is not that it proves the code right; it is that it catches the day you change something and break something else. Untested code is a hypothesis.
Everything in this course's calculation library is tested this way, and the tests have caught real errors while it was being written — including a beam check that was 12.5 % wrong and would otherwise have been quoted in a lesson.
Try it
Sequence, condition, loop
A member-sizing routine, assembled from its steps. Reorder it or break a condition, and read what the routine would then return.
Break a condition
Each of these is a one-character change in real code.
Use the up and down buttons beside each step to reorder the routine. Everything here works from the keyboard; nothing requires dragging.
- 1Read the inputsSpan, load, deflection limit, catalogue.
- 2Compute the design momentM = wL²/8 for this case.
- 3Sort the catalogue by massLightest first, so the first pass is the lightest that works.
- 4Loop through the catalogueOne section at a time.
- 5Check strengthIs the moment resistance at least the design moment?
- 6Check deflectionIs the deflection under the limit?
- 7Return the first section that passes bothAnd stop.
- 8If none passes, say soDo not return the last one tried.
The routine is in a working order with sound conditions. It returns the lightest section that satisfies both checks, and says so when none does.
What this shows: A broken routine does not usually crash. It returns a plausible number, which is why a test with a known answer is the only real check.
Check yourself
A colleague's script sizes beams by looping through a catalogue and returning the first section that passes. It has no tests. What is the most useful thing to do before relying on it?
Worked example
Reading a loop that runs one time too few
Given
- A script places nodes along a beam:
for i in range(n): x = i * L / n - It is asked for 5 nodes on a 10 m beam
Find
What it produces, and whether the error is visible
Worked example
A condition that is never true
Given
- A script flags members whose utilisation exceeds 1.0:
if utilisation > 1.0: flag(member) - Utilisation is computed as a percentage elsewhere in the script
Find
What the script reports, and how it would be noticed
Practice
A loop for i in range(n) with x = i * L / n is asked for 5 nodes on a 10 m beam. What is the coordinate of the last node it produces, in metres?
Check yourself
Why is a wrong condition more dangerous than a wrong formula in a script?
Check yourself
What should a script that generates a model always report back?
Summary
- The hard part of an algorithm is making the steps unambiguous
- Naming a value once is the difference between one change and eleven
- Conditions carry the judgement and hide the edge cases
- A function is the unit of reuse, of testing and of understanding
- A tool that returns a plausible number for impossible input is worse than one that stops
This is educational material. It uses simplified examples to teach principles, and must not be relied on for real design or safety-critical decisions. Module overview and checkpoint