computational problem

A computational problem is the job description, not the worker. Before you can talk about an algorithm, you have to say precisely what counts as a correct answer. "Sort these numbers" is a problem; "add up the salaries" is a problem; "find the shortest driving route" is a problem. The problem says what relationship the output must have to the input — it does not say how to compute it. That "how" is the algorithm's job.

Formally, a computational problem is specified by two things: the set of legal inputs, and, for each input, what makes an output correct. We usually write it as a relation between inputs and acceptable outputs. Take Sorting: the inputs are finite sequences of comparable items, and an output is correct when it contains exactly the same items rearranged into nondecreasing order. Notice this pins down the answer without naming any method — merge sort, quicksort, and a slow bubble sort all solve the very same problem, and they are judged correct by this one specification.

Getting the problem statement right is half the battle, and it is where vagueness causes real bugs. "Find a good route" is not yet a problem until you say good how — shortest in distance, fastest in time, fewest turns? A computational problem is the contract an algorithm must satisfy; until the contract is written down precisely, you cannot even say whether an algorithm is correct, let alone how fast it is.