Start with the Problem, Not the Steps
Suppose someone says:
“Find the average test score.”
That sounds simple, but an algorithm cannot act on the sentence alone.
We need to know:
- What scores are provided?
- How many scores are there?
- Are all inputs valid numbers?
- What should happen if the list is empty?
- What form should the result take?
A computational problem becomes clearer when we separate it into parts:
\[ \boxed{ \text{problem} \to \text{inputs} \to \text{process} \to \text{outputs} } \]That structure is often called an input-process-output model, or simply an IPO model.
The Problem Statement
A problem statement describes what must be accomplished.
A useful statement should answer:
- What is being asked?
- What information is available?
- What result counts as a solution?
For example:
“Given the length and width of a rectangle, find its area.”
This already identifies:
- two inputs: length and width,
- one process: multiplication,
- one output: area.
A good algorithm begins with a well-defined problem.
Inputs
An input is information supplied to a process.
Inputs may be:
- numbers,
- text,
- lists,
- tables,
- matrices,
- graphs,
- files,
- measurements,
- logical values such as true or false.
Example
For the area problem,
\[ A=\ell w, \]the inputs are
\[ \ell \quad\text{and}\quad w. \]The algorithm cannot compute the area until values for those inputs are known.
Constraints and Preconditions
Inputs may need to satisfy conditions before the process is valid.
These conditions are called constraints or preconditions.
Example
For a rectangle, it is usually reasonable to require
\[ \ell>0 \]and
\[ w>0. \]For division,
\[ \frac{a}{b}, \]we require
\[ b\neq0. \]For a square root over the real numbers,
\[ \sqrt{x}, \]we require
\[ x\geq0. \]Identifying input constraints prevents invalid operations later.
Processes
A process is the sequence of operations that transforms input into output.
For rectangle area:
\[ A=\ell w. \]The process is multiplication.
For the mean of \(n\) values,
\[ \bar{x} = \frac{x_1+x_2+\cdots+x_n}{n}, \]the process requires:
- sum the values,
- count how many values there are,
- divide the sum by the count.
The process may contain arithmetic, logic, repetition, lookup, comparison, or other operations.
Intermediate State
Many algorithms need temporary values while they work.
These temporary values form the algorithm's state.
Example: Running Total
To sum
\[ 4,\ 7,\ 3, \]
we might keep a variable called total.
Start:
\[ \text{total}=0. \]After adding \(4\):
\[ \text{total}=4. \]After adding \(7\):
\[ \text{total}=11. \]After adding \(3\):
\[ \text{total}=14. \]The final output is \(14\), but the intermediate totals are part of the process state.
Outputs
An output is the information produced by a process.
Outputs may be:
- a number,
- a true/false result,
- a sorted list,
- a graph,
- a report,
- a modified data structure,
- an error message,
- or several values at once.
For the rectangle example,
\[ A=\ell w, \]the output is the area \(A\).
The output should match the problem statement.
Validation
Validation checks whether inputs or outputs satisfy expected conditions.
Input Validation
If age must be a nonnegative number, reject
\[ -7 \]as invalid.
Output Validation
If an algorithm computes a probability, the result should normally satisfy
\[ 0\leq P\leq1. \]If the output falls outside the valid range, something may be wrong with the input, algorithm, or assumptions.
Validation gives an algorithm a way to protect its own meaning.
The IPO Model
The IPO model is simple, but it is powerful because it prevents several common mistakes:
- solving the wrong problem,
- using missing inputs,
- performing invalid operations,
- producing an output that does not answer the original question.
Problems as Transformations
Many computational problems can be viewed as transformations:
\[ \boxed{ \text{input space} \longrightarrow \text{output space} } \]For example,
\[ (\ell,w) \longmapsto \ell w. \]This is closely related to a function.
But the process may contain many internal steps before the output appears.
That gives us two useful views:
- function view: what output corresponds to each input?
- algorithm view: how do we compute that output?
Input Type and Structure
The structure of input affects the algorithm.
For example, these are not the same input:
\[ 5 \]and
\[ (5,2,8). \]The first is a single number. The second is an ordered collection.
Likewise, a matrix such as
\[ \begin{bmatrix} 1&2\\ 3&4 \end{bmatrix} \]requires different operations from a scalar.
An algorithm should know what kind of object it expects.
\[ \boxed{ \text{valid operation depends on input structure} } \]Multiple Outputs
A process can produce more than one result.
Example
Given two numbers \(a\) and \(b\), produce:
\[ a+b \]and
\[ ab. \]The output can be represented as an ordered pair:
\[ \boxed{ (a+b,\ ab) } \]A more complex process might return:
- a numerical answer,
- a status flag,
- and a diagnostic message.
Output structure matters just as input structure does.
Missing and Invalid Input
Real problems often include imperfect input.
Suppose an algorithm computes
\[ \text{average} = \frac{\text{sum}}{\text{count}}. \]If the list is empty, then
\[ \text{count}=0, \]and division by zero would occur.
A robust specification should decide what happens:
- reject the input,
- return a special value,
- ask for more data,
- or apply another stated rule.
Handling invalid input is part of problem design, not an afterthought.
Problem Specifications
A problem specification states what the algorithm is supposed to do clearly enough that we can judge whether a proposed solution is correct.
A useful specification may include:
- input types,
- input constraints,
- required output,
- special cases,
- acceptable error or tolerance,
- performance requirements.
Example Specification
Problem: Compute the mean of a nonempty list of real numbers.
Input:
\[ (x_1,x_2,\ldots,x_n), \qquad n\geq1. \]Output:
\[ \bar{x} = \frac{1}{n} \sum_{i=1}^{n}x_i. \]Now the task is precise enough to design and test an algorithm.
Practical Applications
Software Design
Programmers define accepted inputs, transformations, and outputs before implementing functions and services.
Spreadsheets
A spreadsheet formula transforms cell inputs into calculated outputs.
Engineering
Models receive parameters and measurements, process them through equations, and return predictions or design quantities.
Business
Pricing, payroll, inventory, and forecasting systems all depend on clearly defined inputs and outputs.
Science
Experiments collect measured input data, process it, and produce derived quantities, summaries, or models.
Worked Examples
Example 1: Rectangle Area
Problem: Find the area of a rectangle.
Inputs:
\[ \ell,\ w>0. \]Process:
\[ A=\ell w. \]Output:
\[ \boxed{A}. \]Example 2: Convert Temperature
Problem: Convert Celsius to Fahrenheit.
Input:
\[ C. \]Process:
\[ F=\frac95C+32. \]Output:
\[ \boxed{F}. \]Example 3: Determine Whether a Number Is Even
Input: integer \(n\).
Process: compute the remainder when dividing by \(2\).
If
\[ n\bmod2=0, \]then output
\[ \boxed{\text{true}}. \]Otherwise output
\[ \boxed{\text{false}}. \]Example 4: Average a List
Input:
\[ (6,8,10,12). \]Process:
\[ 6+8+10+12=36, \] \[ n=4, \] \[ \frac{36}{4}=9. \]Output:
\[ \boxed9. \]Example 5: Validate a Probability
Input:
\[ p=1.3. \]A valid probability must satisfy
\[ 0\leq p\leq1. \]Since \(1.3\) violates the constraint, the algorithm should reject the input rather than continue as though it were valid.
Example 6: Multiple Outputs
Given
\[ a=4, \qquad b=7, \]produce both sum and product.
\[ a+b=11, \] \[ ab=28. \]Output:
\[ \boxed{(11,28)}. \]Common Errors
1. Starting to Code before Defining the Problem
Implementation cannot repair an unclear specification.
2. Failing to Identify Input Constraints
Operations such as division and square roots require valid domains.
3. Confusing Intermediate State with Final Output
Temporary values help the process but may not belong in the final result.
4. Producing an Output That Does Not Answer the Question
A correct calculation can still solve the wrong problem.
5. Ignoring Empty, Missing, or Malformed Input
Special cases should be considered when the problem is specified.
6. Assuming Input Type Does Not Matter
A number, list, matrix, and graph support different operations and require different processing.
Practice
Identify the IPO Structure
A program receives a radius \(r\) and returns the area of a circle. Identify the input, process, and output.
Check Answer
Input: \(r\)
Process:
\[ A=\pi r^2 \]Output: \(A\)
Find the Constraint
An algorithm computes
\[ \frac{a}{b}. \]What input constraint is necessary?
Check Answer
\[ \boxed{b\neq0}. \]Find the Invalid Case
An averaging algorithm accepts a list of values. What special case must be handled before dividing by the count?
Check Answer
The empty-list case, because then the count is \(0\).
Multiple Output
If the inputs are \(x=3\) and \(y=5\), and the process returns both \(x+y\) and \(x-y\), what is the output pair?
Check Answer
\[ \boxed{(8,-2)}. \]State
Is a running total used while summing a list usually an input, an output, or intermediate state?
Check Answer
\[ \boxed{\text{intermediate state}}. \]The Deeper Idea
Computational thinking begins by separating a problem into structural roles.
\[ \boxed{ \text{problem} = \text{inputs} + \text{constraints} + \text{process} + \text{outputs} } \]This connects several earlier Malone Math ideas:
- functions distinguish domain, rule, and range,
- relations connect inputs with outputs,
- measurement identifies valid units and quantity types,
- logic determines whether conditions are satisfied,
- algorithms make the transformation process explicit.
A vague problem becomes computational only when its structure is clear enough to test.
That is why the first question is usually not:
“What steps should I write?”
It is:
“What exactly is the problem, and what information must move from input to output?”
Summary
- A problem statement defines what must be accomplished.
- Inputs are the information supplied to a process.
- Constraints and preconditions identify which inputs are valid.
- A process transforms input into output.
- Intermediate state stores temporary information used during processing.
- Outputs are the results produced by the process.
- Validation checks whether inputs or outputs satisfy expected conditions.
- The IPO model separates input, process, and output into clear roles.
- Many problems can be viewed as transformations from an input space to an output space.
- Input type and structure determine which operations make sense.
- Algorithms may return one output or many outputs.
- Missing and invalid input should be considered as part of the problem specification.
- A good specification makes it possible to decide whether an algorithm is correct.
The most reliable way to design an algorithm is to formalize the problem first. Once the inputs, constraints, process, and outputs are clear, the algorithm becomes a structured solution rather than a guess at what steps might work.
Algorithms and Computational Thinking
- Previous: Procedures and Algorithms
- Algorithms and Computational Thinking — return to the lesson directory.