IB Digital Society 3.2C Representing Algorithms Notes

3.2C Representing Algorithms

Writing an Algorithm Down

1. An algorithm in someone's head is not much use; to be shared, checked, and built it must be written down in a form other people or a computer can follow.
2. There are three common representations: natural language, a flowchart, and code. All three can describe the same logic but aim at different readers and stages, from a rough sketch to a finished program.
3. How something is represented is also a question of accountability. A rule kept only as code on a company's servers stays invisible to the people it affects. Written in plain language, the same rule can be read and challenged by them (power, values and ethics).

Natural Language and Pseudocode

1. The simplest representation is plain natural language: steps written as ordinary sentences. Anyone can read it with no training, ideal for explaining to a non-expert or a first draft.
2. Its weakness is ambiguity. A phrase like keep going for a while has several readings. A person fills the gap with common sense; a computer cannot.
3. Pseudocode keeps the readability of plain language but adds the structure of code, with clear steps, conditions, and loops, while staying free of any one programming language's rules. It is the middle ground where logic is worked out before real code is written.

Flowcharts

1. A flowchart represents an algorithm as a diagram: boxes for steps joined by arrows showing order. Its strength is that the flow, especially branches and loops, can be taken in at a glance.
2. Standardised shapes make them readable: an oval marks start or end, a rectangle is a process step, and a diamond is a decision that splits the path in two.
   1. The trade-off is space: flowcharts are excellent for small or branch-heavy algorithms, but a large one becomes a sprawling diagram harder to read than a few lines of pseudocode.

Code and Programming Languages

1. The most precise representation is code, written in a programming language such as Python or Java. Code is the only form a computer can run, and it is exact to the last character.
2. The cost of that precision is rigidity. Code has strict grammar, so a single missing symbol stops it working, and reading it fluently needs training a general audience lacks. It is tied to a particular language, though the algorithm underneath could be written in any.
   1. A processor only understands low-level instructions, so code is translated again before running, either compiled ahead of time or interpreted line by line. Which language a team picks is usually a matter of convenience; the machine can run the same logic either way.

Choosing the Right Representation

1. No single representation is best; the right choice depends on purpose and audience. Always ask who needs to read this and what they need to do with it.
2. Natural language is best for explaining an idea. A flowchart shows every branch clearly. Only code can hand the algorithm to a machine. Most projects move through several forms in turn, since each catches problems the others miss.
   1. A navigation app shows all three: a designer describes the routing idea in words for the product team, draws decision points as a flowchart to check detours and closed roads, then writes the code that runs on millions of phones.

Tracing an Algorithm

1. You can check an algorithm by tracing it: following it step by step by hand, tracking every value as it changes. This is also called a desk check.
2. A trace uses a small table, one column per variable, adding a row each time a value updates. It reveals whether the result is right and, when it is not, exactly which step goes wrong.
   1. Real systems have too many inputs to check by hand, so developers write automated tests across thousands of cases, though even that only samples the possibilities rather than proving correctness. Working a few cases still builds the intuition to trust or doubt a larger system.