Computing is fundamentally concerned with solving problems. Although computers are capable of performing enormous numbers of operations rapidly, the usefulness of a computer depends on the quality of the instructions and methods used to direct those operations. A computer does not independently understand a human problem merely because the problem has been presented to it. The problem must first be understood, represented in an appropriate form, and transformed into a sequence of operations that a computing system can perform.

Consider a university that wants to determine the academic standing of every student at the end of a semester. The available information may include course units, grades, grade points and institutional rules. The task is not simply to "use a computer." Someone must first determine what data are required, how the grade point average will be calculated, what rules determine academic standing, how invalid data will be handled and how the final results will be presented. Only after these issues have been clearly defined can a reliable computer-based solution be developed.

Problem solving therefore comes before programming. Programming is one means of implementing a solution, but a poorly understood problem will usually lead to a poorly designed program. For this reason, the study of problem solving develops ways of thinking that are useful before a student begins writing substantial computer programs.

1.2 Meaning of Computing

Computing is broader than the act of operating a computer. It includes the principles, techniques and technologies involved in designing algorithms, developing software, processing data, constructing computer systems, managing information, communicating through networks and applying computational methods to real-world problems.

For example, when a bank processes a transfer, several computing activities may occur. The system receives transaction data, validates account information, checks relevant conditions, updates stored records, communicates with other systems where necessary and reports the result to the customer. These activities involve data, algorithms, software, hardware, networks and security working together.

1.3 Core Concepts of Computing

Before studying problem solving in detail, it is useful to understand several fundamental ideas that occur repeatedly in computing.

Data:

Data are representations of facts, observations, measurements or symbols that can be stored and processed. Examples include a student's matriculation number, a temperature reading, an examination score and a digital image.

Information:

Information is data that have been processed, organized or interpreted in a way that gives them meaning or usefulness in a particular context.

Processing:

Processing refers to operations performed on data in order to transform them, analyse them or produce useful results. Examples include sorting names, calculating totals, comparing values and searching a database.

Algorithm:

An algorithm is a finite and well-defined sequence of steps for solving a problem or accomplishing a task. Algorithms will be examined in detail in later chapters because they form a central bridge between problem analysis and programming.

Program:

A program is a set of instructions expressed in a form that can be executed by a computer. A program may implement one or more algorithms.

Input, Processing and Output:

Many elementary computing tasks can be understood using the input-process-output model.

Input is the data supplied to the system. Processing consists of the operations performed on that data. Output is the information or result produced.

Not every computing system can be completely described by a single simple input-process-output sequence. Interactive systems may repeatedly receive input and produce output, while control systems may operate continuously. Nevertheless, the model provides a useful starting point for analysing many introductory problems.

1.4 Meaning of a Problem

A problem normally contains something that is known and something that must be determined, achieved or changed. In mathematics, a problem may provide values and ask for an unknown quantity. In business, a problem may involve finding an efficient method of allocating limited resources. In computing, a problem may require the transformation of given data into a specified output.

1.5 Problems in Computing

A computing problem is a problem for which computation forms an important part of the solution. Such problems may involve numerical calculation, searching, sorting, decision-making, data transformation, scheduling, simulation, communication or control.

Examples include:

• calculating students' grade point averages;
• determining whether a customer has sufficient account balance for a withdrawal;
• finding a particular record in a database;
• arranging examination scores in order;
• determining the shortest or most appropriate route between locations;
• checking whether login credentials satisfy authentication requirements;
• calculating an employee's pay from hours worked and applicable rates;
• determining whether a number is prime;
• processing registration information;
• generating reports from stored records.

The important point is that a real-world request must usually be converted into a more precise computational problem before a program can be written.

1.6 Meaning of Problem Solving

Problem solving is therefore both a thinking process and an action process. It requires reasoning about what is wrong or what is required, followed by the development and evaluation of a solution.

For a simple problem, the solution may be obvious. For a more complex problem, several possible approaches may exist. The problem solver must then compare alternatives and determine which method is suitable under the given conditions.

1.7 Computational Problem Solving

Computational problem solving requires precision. A human being may understand an instruction such as "give excellent students special recognition" because the surrounding context may explain what "excellent" means. A computer cannot reliably execute such an instruction until the criterion has been stated precisely.

For example, the rule might be defined as:

The precise condition can then be represented algorithmically and eventually translated into a programming language.

1.8 Elements of a Computing Problem

Many computing problems become easier to understand when they are broken into identifiable elements.

Inputs:

Inputs are the data required before the problem can be solved.

Outputs:

Outputs are the results that the solution is expected to produce.

Processing Requirements:

These are the operations or transformations that must be performed on the inputs to obtain the outputs.

Constraints:

Constraints are conditions or restrictions that limit acceptable solutions. A constraint may concern time, memory, cost, available data, permitted values, security or rules imposed by the problem.

Conditions:

Some problems require different actions depending on whether particular conditions are true or false.

1.9 From Problem to Solution

A useful introductory view of computational problem solving is:

Understand the Problem:

Determine what is actually being requested. Ambiguous terms should be clarified before solution development begins.

Analyse the Problem:

Identify the inputs, required outputs, relationships, rules and constraints.

Design the Solution:

Develop a logical procedure for obtaining the required output. The solution may later be represented using an algorithm, flowchart, pseudocode, decision table or another suitable method.

Implement the Solution:

Translate the designed solution into an operational form. In computing, this frequently involves writing a program.

Test and Evaluate:

Use appropriate test cases to determine whether the solution behaves as expected.

Refine:

Correct defects and improve the solution where necessary. The complete general problem-solving process will be developed more fully in a later chapter.

1.10 Characteristics of Effective Problem Solving

Effective problem solving in computing exhibits several important qualities.

Clarity:

The problem and its requirements should be stated clearly enough to avoid conflicting interpretations.

Correctness:

The proposed solution should produce the required result for the cases it is intended to handle.

Logical Consistency:

The steps of the solution should follow a coherent order without contradiction.

Efficiency:

Where alternatives exist, the use of time, memory and other resources may be considered. Efficiency becomes increasingly important as the size of a problem grows.

Generality:

A useful solution should normally solve the intended class of problems rather than only one example.

1.11 Problem-Solving Skills

Problem-solving ability is developed through several complementary intellectual skills.

Analytical Thinking:

Analytical thinking involves breaking a situation into smaller components and examining their relationships.

Logical Reasoning:

Logical reasoning involves drawing conclusions according to valid relationships and stated conditions.

Pattern Recognition:

Recognizing similarities between a new problem and previously solved problems can suggest useful solution strategies.

Abstraction:

Abstraction involves concentrating on the information that is relevant to a problem while temporarily ignoring unnecessary detail.

Decomposition:

Decomposition divides a complex problem into smaller and more manageable subproblems.

Evaluation:

Evaluation involves determining whether a proposed solution satisfies the requirements and identifying weaknesses that require correction.

1.12 Computers as Tools for Problem Solving

Computers are valuable problem-solving tools because they can execute clearly specified instructions rapidly and consistently. They can process large amounts of data, store information, perform repetitive calculations and communicate results over networks.

Computers are particularly useful when a problem involves:

• large quantities of data;
• repeated operations;
• complex calculations;
• high-speed processing;
• accurate storage and retrieval;
• automation;
• simulation;
• communication between systems.

However, the presence of a computer does not automatically make a solution correct. A computer can execute an incorrect algorithm accurately and repeatedly. The quality of the output therefore depends on the quality of the data, rules, algorithm, implementation and testing.

1.13 Human and Computer Roles in Problem Solving

Humans and computers contribute different capabilities to problem solving.

Effective computational problem solving therefore depends on combining human reasoning with computational execution.

1.14 Practical Examples of Computing Problems

Example 1: Average of Three Scores:

Suppose a program must calculate the average of three examination scores.

Example 2: Determine Whether a Number Is Even:

A whole number is even if it is divisible by 2 without a remainder.

Example 3: Find the Larger of Two Numbers:

This example demonstrates an important point: a careful solution must account for equality rather than assuming that one value must always be greater than the other.

Example 4: Calculate a Simple Student Grade:

Suppose a simplified grading rule states:

• 70–100: A
• 60–69: B
• 50–59: C
• 45–49: D
• 40–44: E
• 0–39: F

For an input score of 67, the solution compares the score with the defined ranges. Since 67 lies between 60 and 69 inclusive, the output is B.

This is more complex than a simple calculation because the solution must select an output according to conditions. Later chapters will show how such decisions are represented using algorithms, flowcharts, pseudocode and programming statements.

1.15 Importance of Problem Solving in Computing

Problem solving is central to nearly every area of computing. Software developers solve problems by designing applications. Network professionals solve communication and connectivity problems. Data specialists solve problems involving the organization and interpretation of data. Cybersecurity professionals solve problems involving threats, vulnerabilities and protection. Artificial intelligence specialists develop computational approaches to problems involving prediction, classification, perception and decision support.

For an undergraduate computing student, learning problem solving provides a foundation for programming because it shifts attention from memorizing language syntax to understanding how solutions are constructed.

The first major challenge in problem solving is not necessarily finding a solution. It is determining precisely what problem must be solved. A solution to the wrong problem may be technically impressive but practically useless.

In computing, this principle is especially important because computers require precise instructions. If the requirements supplied to a software developer are incomplete or ambiguous, the resulting program may behave exactly as programmed while still failing to satisfy the user's actual need.

2.2 Problem Identification

Problem identification asks a fundamental question: What exactly needs to be solved?

A reported symptom should not automatically be treated as the underlying problem. For example, users may report that an online application is "too slow." The observed slowness is real, but its cause could be inefficient software, an overloaded server, a slow database query, poor network connectivity, very large files or another factor. Effective problem solving distinguishes the observed effect from the underlying cause where that distinction matters.

Questions Used in Problem Identification:

Useful questions include:

• What is happening now?
• What should be happening?
• Who or what is affected?
• When does the problem occur?
• What evidence shows that a problem exists?
• What result is expected?
• What conditions must a successful solution satisfy?

2.3 Defining a Problem Correctly

After identifying the general issue, it must be defined with sufficient precision. A useful problem definition establishes the scope and expected outcome without prematurely assuming a particular implementation.

The improved statements are more useful because they specify what information is involved and what outcome is required.

2.4 The Problem Statement

A good computational problem statement should make it possible to answer questions such as:

• What data will be provided?
• What result must be produced?
• What rules determine that result?
• What values are valid?
• Are there exceptional cases?

This statement identifies the input, establishes a validity condition, specifies the required output and gives the mathematical relationship needed to produce the result.

2.5 Problem Analysis

Problem analysis answers the question: What must be understood before the solution can be constructed?

For many introductory computational problems, analysis can begin with four questions:

1. What information is available?
2. What result is required?
3. What relationships connect the available information to the required result?
4. What restrictions or special cases must be considered?

Worked Analysis: Celsius to Fahrenheit Conversion:

Notice that the analysis is performed before any Python or C statement is written. Once the relationship has been understood, implementing it in a programming language becomes comparatively straightforward.

2.6 Identifying Inputs and Outputs

One of the simplest and most useful ways to analyse a computational problem is to identify its inputs and outputs explicitly.

Input:

Input is the data supplied to a solution or system for processing.

Output:

Output is the result produced after processing.

Derived Values:

Some values are neither original inputs nor final outputs. They are calculated during processing and used to obtain the final result. Such values may be called intermediate or derived values.

2.7 Requirements and Constraints

Requirements:

For example, a program designed to process examination scores may be required to accept valid scores, calculate grades and display results.

Constraints:

Examples of constraints include:

• a score must lie between 0 and 100;
• a PIN must contain exactly four digits;
• a transaction cannot exceed an applicable limit;
• a system may have limited memory;
• a result may be required within a specified period;
• only authorized users may access particular information.

Why Constraints Matter:

Ignoring constraints can produce a solution that works for ideal examples but fails in real use.

2.8 Assumptions in Problem Solving

Assumptions are sometimes necessary, but they should be reasonable and explicit. Hidden assumptions can cause errors.

Good problem analysis therefore distinguishes facts supplied by the problem from assumptions introduced by the solver.

2.9 Problem Decomposition

Large computing systems are rarely designed as one indivisible task. Breaking them into components reduces complexity and makes analysis, implementation and testing more manageable.

2.10 Types of Problems

Problems can be classified in several ways. In this course, an especially important distinction is between routine and non-routine problems. Another useful distinction is between well-defined and ill-defined problems.

These classifications are not absolute descriptions of difficulty. A problem that is routine for an experienced programmer may be non-routine for a beginner because the experienced programmer already knows an established method.

2.11 Routine Problems

Routine problems usually involve familiar structures and known solution methods.

Examples:

• calculating the area of a rectangle when length and width are known;
• converting Celsius temperature to Fahrenheit using a given formula;
• calculating the average of a known collection of scores;
• calculating simple interest from principal, rate and time;
• determining whether a number is divisible by another number.

2.12 Non-Routine Problems

Non-routine problems require more than substituting values into a familiar formula. The solver may need to discover relationships, combine several techniques, compare alternative approaches or reformulate the problem.

Routine and Non-Routine Problems Compared:

2.13 Well-Defined and Ill-Defined Problems

Well-Defined Problems:

The inputs and required output are clear, and a proposed answer can be tested objectively.

Ill-Defined Problems:

Many real-world problems begin in an ill-defined form. Part of the problem-solving process is to investigate the situation and convert the vague request into sufficiently clear requirements.

2.14 Computational and Non-Computational Aspects of Problems

Not every part of a real-world problem should necessarily be solved by a computer. Some parts involve human judgement, policy, ethics, negotiation or contextual understanding.

An effective problem solver therefore asks not only, “Can this be computerized?” but also, “Which parts should be automated, and which require human responsibility or judgement?”

2.15 Recognizing Patterns in Problems

Pattern recognition involves identifying similarities, repetitions or structures that connect a new problem with other problems.

Suppose a student has already learned how to determine the largest of two numbers. The problem of determining the largest of three numbers has a related structure: values must still be compared according to their magnitude. Recognizing this relationship can help the student develop the new solution.

Recognizing such patterns is important because computing frequently involves reusing general solution ideas in new contexts.

2.16 Selecting Relevant Information

A problem description may contain information that is not required for the particular result being calculated. Effective analysis separates relevant data from irrelevant detail.

This does not mean the other information is useless in every context. It means it is not relevant to the specific problem currently being solved.

2.17 Developing Test Cases from the Problem Definition

A well-defined problem should provide enough information to begin thinking about how a future solution will be tested. A test case consists of selected input conditions together with the behaviour or output expected from the solution.

Test cases should not contain only ordinary values. Boundary and exceptional conditions may reveal weaknesses that normal examples do not expose.

Thinking about test cases during analysis often exposes missing requirements. If the problem statement does not say what should happen when a score is outside the valid range, the analyst has discovered an ambiguity that should be resolved before implementation.

2.18 Applied Problem Analysis

The following examples combine the ideas developed throughout the chapter.

Example 1: Calculate a Student's Total and Average:

Example 2: Determine Admission Eligibility:

Suppose, purely for this example, that an institution defines eligibility for a particular process as a score of at least 50.

Example 3: Find the Smallest of Three Values:

Example 4: Automated Teller Machine Withdrawal:

This example demonstrates why real computing problems require careful analysis. A simplistic rule such as “if balance is greater than the withdrawal amount, give cash” ignores authentication, equality at the boundary, applicable limits, transaction charges where relevant, permitted denominations and other operational requirements.

The purpose of problem analysis is therefore not to make simple tasks unnecessarily complicated. It is to identify the details that genuinely determine whether a solution will work correctly.

Once a problem has been clearly identified and analysed, the next task is to develop a method for solving it. In computing, this method is commonly expressed as an algorithm.

An algorithm is one of the most important ideas in computing because it provides the logical structure of a solution before that solution is translated into a programming language. Programming languages may differ in syntax, but the underlying problem-solving logic can often be represented independently of any particular language.

3.2 Meaning of an Algorithm

Several ideas in this definition are important. The steps must be arranged in a meaningful order, each step must be sufficiently clear, the procedure must eventually stop, and the steps must be capable of being carried out.

An algorithm does not have to be written in a programming language. It may be expressed in ordinary structured language, pseudocode, a flowchart or another precise representation.

3.3 Why Algorithms Are Important

Algorithms are important because they separate problem-solving logic from programming syntax. This allows the problem solver to concentrate on the structure of the solution before dealing with the detailed rules of a programming language.

Algorithms also help to:

• clarify the logic of a solution;
• detect missing steps before implementation;
• communicate a solution to other people;
• support testing and verification;
• make translation into different programming languages easier;
• compare alternative solution methods.

3.4 Characteristics of a Good Algorithm

A useful algorithm should possess certain important characteristics.

Definiteness:

Each step should be stated clearly enough that its meaning is not ambiguous.

Finiteness:

The algorithm should terminate after a finite number of steps for every valid input for which it is intended to produce a result.

Effectiveness:

Each step should be sufficiently basic and practical that it can actually be carried out.

Input:

An algorithm may receive zero or more input values depending on the problem.

Output:

An algorithm should produce at least one meaningful result for the problem it solves.

Correctness:

The algorithm should produce the required result for all valid cases within the problem definition.

Generality:

Where appropriate, an algorithm should solve a class of problems rather than only one specific numerical example.

3.5 Inputs and Outputs in Algorithms

Inputs are values supplied to the algorithm, while outputs are the values or messages produced after processing.

If the inputs are 8 and 5, the output is 40.

3.6 Finiteness and Definiteness

Finiteness requires an algorithm to stop after a limited number of operations. An algorithm that continues indefinitely without reaching a result does not satisfy this property for the intended problem.

Definiteness requires every instruction to be stated precisely.

A computer requires the second form because it specifies exactly what operation should occur.

3.7 Effectiveness and Correctness

An algorithm should contain operations that can actually be performed. For example, “determine instantly whether any arbitrary computer program will eventually stop for every possible input” is not a practical elementary step.

Correctness means that the algorithm gives the right result according to the problem specification.

3.8 Generality of Algorithms

A useful algorithm should normally solve the general form of a problem.

The second form can solve many rectangle-area problems, not only one particular instance.

3.9 Steps in Algorithm Development

Algorithm development should follow the earlier stages of problem analysis.

1. Understand the problem.
2. Identify required inputs.
3. Identify required outputs.
4. Identify the relationships and conditions involved.
5. Break the solution into logical steps.
6. Arrange the steps in the correct order.
7. Test the steps using representative values.
8. Refine the algorithm if necessary.

If C = 20, then F = 68.

3.10 Sequence in Algorithms

Many simple problems consist entirely of sequence.

For quantity = 6 and unit price = 2500:

Total = 6 × 2500 = ₦15,000.

3.11 Selection in Algorithms

Selection is required whenever the solution depends on a decision.

For score = 65, the algorithm displays “Pass.” For score = 32, it displays “Fail.”

Multiple Selection:

Some problems require more than two alternatives.

The conditions are checked from the highest range downward. Once a condition is satisfied, the corresponding grade is selected.

3.12 Repetition in Algorithms

Repetition avoids writing the same instruction many times.

The output is:

1, 2, 3, 4, 5

3.13 Algorithm Tracing

Tracing helps the problem solver test logic before implementation.

Let A = 4 and B = 7.

The final output is 22.

3.14 Algorithms for Arithmetic Problems

Arithmetic algorithms are common introductory examples because the relationships are often clear and easy to verify.

Example: Simple Interest:

If principal = ₦60,000, rate = 5 and time = 3 years:

Interest = (60,000 × 5 × 3) / 100 = ₦9,000.

Example: Average of Four Numbers:

For 50, 60, 70 and 80:

Total = 260 and average = 65.

3.15 Algorithms for Decision Problems

Decision problems require conditions.

Example: Even or Odd Number:

The MOD operation returns the remainder after integer division. If the remainder after division by 2 is zero, the number is even.

Example: Larger of Two Values:

3.16 Algorithms for Repetitive Problems

Some tasks involve repeated accumulation or processing.

Example: Sum of the Numbers 1 to 5:

The successive values of sum are:

1, 3, 6, 10 and 15.

Therefore, the final output is 15.

Generalizing the Problem:

A more general version can read a positive integer N and calculate:

1 + 2 + 3 + ... + N

3.17 Evaluating an Algorithm

Before implementation, an algorithm should be evaluated against the problem requirements.

Useful questions include:

• Does it produce the correct result for normal inputs?
• Does it handle boundary conditions correctly?
• Does it handle invalid inputs where required?
• Does it eventually terminate?
• Are all steps clear?
• Are required outputs actually produced?
• Is the method unnecessarily complicated?

3.18 Algorithm Efficiency at Introductory Level

Two correct algorithms may require different amounts of computational work. The study of how resource requirements grow with problem size is an important area of computer science.

At introductory level, efficiency can be understood by comparing unnecessary and necessary work.

Efficiency should not be confused with correctness. A fast algorithm that gives the wrong result is not a useful solution.

3.19 From Algorithm to Program

An algorithm expresses the logical method of solving a problem. A program expresses that method using the rules of a programming language.

This same algorithm can later be implemented in Python, C or another programming language without changing its essential logic.

Not every problem has an obvious step-by-step solution. Some problems are too complex for a simple direct method, while others have exact algorithms that become impractical when the amount of data becomes very large. There are also problems for which no algorithm can solve every possible instance.

These facts lead to two important ideas in problem solving: heuristics and solvability. A heuristic provides a practical strategy for finding a useful solution when an exact method is difficult, expensive or unnecessary. Solvability concerns whether a problem can, in principle, be solved by an algorithm under the stated conditions.

4.2 Meaning of a Heuristic

A heuristic does not necessarily guarantee the best possible solution. Instead, it is intended to guide the search toward a useful answer efficiently.

4.3 Algorithms and Heuristics Compared

The distinction is not always absolute. A heuristic can itself be implemented as an algorithm. The important distinction is whether the method guarantees the required exact or optimal result.

4.4 Why Heuristics Are Used

Heuristics are useful for several reasons.

Large Search Spaces:

A problem may have so many possible solutions that examining every one would require excessive time.

Incomplete Information:

The solver may not have enough information to construct a fully exact model.

Time Constraints:

A useful solution may be needed quickly even if a more exhaustive search could eventually produce a better result.

Approximation Is Acceptable:

In some applications, a sufficiently good result is more valuable than an exact result that arrives too late.

4.5 Common Forms of Heuristic Reasoning

Heuristics may take many forms depending on the problem.

Use of Experience:

A solver may apply knowledge gained from similar problems.

Pattern-Based Reasoning:

A familiar pattern may suggest a likely solution method.

Prioritization:

The solver may investigate the most promising possibilities first.

Simplification:

The problem may be temporarily simplified so that useful progress can be made.

Incremental Improvement:

A solution may be improved step by step rather than constructed perfectly in one operation.

4.6 Rule-of-Thumb Strategies

Examples include:

• check the most likely cause of a fault before rare causes;
• start with the simplest plausible explanation;
• test small examples before large ones;
• solve the easiest subproblem first if it simplifies the rest.

Such rules can be useful, but they should not be mistaken for universal laws.

4.7 Greedy Choice as a Heuristic Idea

A greedy strategy repeatedly chooses an option that appears best at the current stage, without necessarily considering every future consequence.

In some problems, a properly designed greedy algorithm can be mathematically proven to produce an optimal solution. In other problems, greedy choice is only a heuristic.

4.8 Search and Exploration

Many problem-solving tasks can be viewed as searching through possible states or possible solutions.

Examples include:

• finding a route;
• choosing a timetable arrangement;
• finding a suitable configuration;
• selecting the best sequence of actions;
• solving a puzzle.

A blind search may examine possibilities without using additional knowledge. A heuristic search uses information about the problem to guide which possibilities are examined first.

4.9 Heuristics in Everyday Computing Problems

Troubleshooting:

When a computer cannot access the Internet, a technician may first check whether other devices can connect, whether Wi-Fi is enabled and whether the network interface is active before investigating more unusual causes.

Password Strength Estimation:

Some systems estimate password strength using heuristic indicators such as length, variety and known patterns. Such indicators provide useful guidance but are not a complete mathematical guarantee that a password is secure.

Search Engines:

Search systems use sophisticated ranking methods to determine which results are likely to be most useful. Ranking involves estimates of relevance rather than a simple universally correct ordering.

Scheduling:

Timetabling systems may use heuristic methods when many interacting constraints make exhaustive exploration impractical.

4.10 Limitations of Heuristics

Heuristics are useful, but they have limitations.

• They may produce suboptimal solutions.
• They may perform well for some cases and poorly for others.
• They may depend heavily on the assumptions built into the heuristic.
• They may require evaluation against better-known solutions.
• They may introduce bias when based on inappropriate rules or data.

4.11 Meaning of Problem Solvability

In introductory computing, it is useful to distinguish among:

• problems that can be solved exactly and efficiently;
• problems that can be solved exactly but may require excessive computational resources for large inputs;
• problems for which useful approximate or heuristic solutions are used;
• problems for which no algorithm can solve every possible instance.

4.12 Solvable Problems

Many familiar problems are solvable.

Examples include:

• sorting a finite collection of numbers;
• finding the maximum value in a non-empty finite list;
• computing the area of a circle from its radius;
• checking whether a finite string contains a specified character;
• calculating the average of a finite set of numeric values.

4.13 Problems with Exact Solutions

Some problems have exact solution methods that are practical for typical input sizes.

This method produces an exact answer.

4.14 Problems with Approximate or Practical Solutions

Some problems can be described exactly, but finding the best possible answer may be computationally expensive for large instances. In such cases, approximation or heuristic methods may be used.

4.15 Computational Difficulty

A problem may be solvable in principle but difficult in practice because the required amount of computation grows very rapidly as the input becomes larger.

Consider a problem in which the system must examine possible arrangements of many objects. The number of possible arrangements can increase dramatically as the number of objects increases.

This illustrates why exhaustive search can become impractical even when the problem itself is finite and solvable.

4.16 Intractable Problems

An intractable problem is not the same as an unsolvable problem. An exact method may exist, but using it on large inputs may require too much time or memory for practical purposes.

4.17 Unsolvable Problems

This idea is important because it shows that computers have theoretical limits. Unlimited processor speed or memory does not remove every limitation. Some problems are not solvable by any general algorithm.

At introductory level, the purpose is not to prove advanced results in computability theory but to understand that computation itself has boundaries.

4.18 The Halting Problem as a Conceptual Example

One of the most famous examples of an undecidable problem is the halting problem.

Alan Turing showed that no such universal algorithm exists for all possible programs and inputs.

4.19 Decidable and Undecidable Problems

For example, determining whether a given integer is even is decidable. An algorithm can divide the integer by 2 and inspect the remainder.

The general halting problem, however, is undecidable.

4.20 Recognizing the Limits of Computation

Understanding computational limits is valuable for several reasons.

• It prevents unrealistic expectations of software.
• It helps distinguish difficult problems from impossible general problems.
• It encourages careful problem reformulation.
• It motivates the use of approximation and heuristics where exact computation is impractical.
• It shows that faster hardware cannot solve every theoretical limitation.

4.21 Choosing Between Exact and Heuristic Approaches

The choice between an exact algorithm and a heuristic approach depends on the nature of the problem.

A problem-solving technique is a structured way of thinking about a problem in order to make progress toward a solution. Some problems can be solved by applying a known formula or algorithm directly. Others are unfamiliar, incomplete, complex or too large to approach in one step. In such situations, the solver requires strategies that help reveal structure, generate ideas, test possibilities or transform the original problem into a more manageable form.

No single technique is appropriate for every problem. A strong problem solver therefore develops a collection of methods and learns when each method is useful. This chapter examines five important techniques: abstraction, analogy, brainstorming, trial and error, hypothesis testing and reduction.

5.2 Why Different Problem-Solving Techniques Are Needed

Problems differ in structure. Some contain too much unnecessary detail. Some resemble previously solved problems. Some require many possible ideas before a good one emerges. Others require testing possible explanations or reducing a complicated situation into smaller parts.

For example:

• Abstraction is useful when irrelevant details make a problem difficult to understand.
• Analogy is useful when the new problem resembles a familiar one.
• Brainstorming is useful when several possible solutions need to be generated.
• Trial and error is useful when possible solutions can be tested safely and progressively.
• Hypothesis testing is useful when the cause of a problem is uncertain.
• Reduction is useful when a problem can be simplified or transformed into a known problem.

These techniques frequently overlap. A programmer may use abstraction to simplify a problem, analogy to recognize a known pattern, and trial and error to test implementation choices.

5.3 Abstraction

Abstraction is fundamental to computing because real-world systems contain enormous amounts of detail. A useful computational model includes the details necessary to solve the problem while leaving out information that does not affect the solution.

Abstraction does not mean that ignored details are unimportant in every context. It means they are not necessary for the current problem.

5.4 Levels of Abstraction

A system may be understood at different levels of detail.

Problem solvers should choose the level of abstraction appropriate to the task.

High-Level Abstraction:

A high-level view emphasizes major functions and relationships while hiding implementation details.

Low-Level Detail:

A lower-level view exposes more specific operations, components or implementation mechanisms.

5.5 Abstraction in Computing

Abstraction appears throughout computing.

Functions and Procedures:

A function can hide several internal operations behind a simple name. The user of the function needs to understand what it does without necessarily knowing every implementation detail.

Data Abstraction:

A user may work with a data structure through defined operations without knowing precisely how the data is stored internally.

Operating Systems:

Applications use operating-system services rather than directly controlling every hardware component.

Networks:

Users send messages without manually controlling every router through which the data passes.

5.6 Analogy

Analogy is powerful because many apparently different problems share the same underlying structure.

Structural Similarity:

Useful analogies depend on similarity in the relevant structure of the problems, not simply superficial resemblance.

5.7 Using Analogy Correctly

An analogy is useful only when the similarities relevant to the solution actually hold. Superficial comparison can produce incorrect reasoning.

A careful use of analogy involves:

1. identifying a familiar problem;
2. identifying the structure that made its solution work;
3. comparing that structure with the new problem;
4. identifying important differences;
5. adapting rather than blindly copying the old solution;
6. testing whether the adapted solution works.

5.8 Brainstorming

Brainstorming is particularly useful when a problem has many possible approaches and the solver wants to avoid choosing the first idea too quickly.

The basic principle is to separate idea generation from idea evaluation. During generation, the aim is to produce possibilities. Evaluation occurs afterward.

Example:

Suppose a university department wants to reduce long queues during student registration. Possible ideas might include:

• online registration;
• appointment scheduling;
• additional registration points;
• automatic validation of student records;
• self-service kiosks;
• extended registration hours;
• better separation of different categories of requests.

The ideas should later be evaluated according to cost, feasibility, security, user accessibility and likely effectiveness.

5.9 Structured Brainstorming

Brainstorming becomes more useful when it is guided by a clear problem statement.

A structured approach may involve:

1. state the problem clearly;
2. define important constraints;
3. generate multiple solution ideas;
4. group related ideas;
5. eliminate ideas that violate essential constraints;
6. compare remaining alternatives;
7. select promising options for further analysis.

5.10 Trial and Error

Trial and error is useful when:

• possible solutions are easy to test;
• failure is inexpensive or safe;
• there is feedback showing whether an attempt improved the situation;
• the solution space is manageable.

5.11 Systematic Trial and Error

Random guessing is not the same as good trial and error. A systematic method keeps track of what has been tried and uses the result of each attempt to guide the next one.

Advantages:

• Simple to apply in manageable situations.
• Can produce useful feedback quickly.
• Can support learning through experimentation.

Limitations:

• May be inefficient when possibilities are extremely numerous.
• May be unsafe when failed attempts have serious consequences.
• Does not guarantee an optimal solution.
• Can become repetitive if results are not recorded and analysed.

5.12 Hypothesis Testing

This form of reasoning is especially useful in troubleshooting and diagnosis.

A general process is:

1. Observe the problem.
2. Propose a possible explanation.
3. Determine what evidence would be expected if the explanation were correct.
4. Perform a test.
5. Compare the result with the expected evidence.
6. Accept, reject or revise the hypothesis.

5.13 Hypothesis Testing in Computing

Computing professionals use hypothesis testing frequently, even when they do not describe it formally.

Software Debugging:

A programmer may hypothesize that a wrong result is caused by an incorrect formula and test the formula separately.

Performance Problems:

A developer may hypothesize that a slow application is caused by repeated database queries and measure query activity.

Hardware Problems:

A technician may hypothesize that unexpected shutdowns are caused by overheating and inspect temperature measurements.

5.14 Reduction

Reduction is extremely important in mathematics and computer science. Instead of solving the original problem directly, the solver asks whether it can be converted into a form that is easier to handle.

5.15 Reduction by Simplification

One form of reduction simplifies a problem by temporarily removing complexity while preserving the essential structure.

Why Simplification Helps:

• It reveals the core structure of the problem.
• It reduces the number of interactions considered at once.
• It creates smaller testable stages.
• It helps identify which complexities genuinely affect the solution.

5.16 Reduction to a Known Problem

Another form of reduction converts an unfamiliar problem into a known one.

Reduction is valuable because established algorithms can be reused once the relationship between problems has been identified correctly.

5.17 Combining Problem-Solving Techniques

Real problems often require several techniques.

This example demonstrates that problem-solving methods should be combined according to the demands of the situation.

5.18 Selecting an Appropriate Technique

Selection should depend on the structure of the problem rather than personal habit. Using the same strategy for every problem limits a solver's effectiveness.

5.19 Applied Problem-Solving Examples

Example 1: Designing a Student Login System:

Example 2: Program Gives Wrong Total:

Example 3: Course Timetable:

The previous chapter introduced several general problem-solving techniques. This chapter develops additional techniques that are especially valuable when a problem requires creative restructuring, progressive movement toward a goal, systematic investigation of causes, formal justification or decomposition into independent subproblems.

The techniques considered are lateral thinking, means-end analysis, focal-object method, morphological analysis, research, root-cause analysis, proof and divide-and-conquer.

Some of these methods emphasize creativity, while others emphasize analysis and logical justification. A skilled problem solver should be comfortable with both forms of reasoning.

6.2 Lateral Thinking

Traditional step-by-step reasoning often proceeds from existing assumptions. Lateral thinking questions whether those assumptions must be retained.

6.3 Applying Lateral Thinking

Lateral thinking can be encouraged through several questions:

• What assumption am I making?
• What if the opposite assumption were considered?
• Can the problem be viewed from the user's perspective?
• Can a step be removed entirely rather than improved?
• Can the order of activities be changed?
• Can a resource serve more than one purpose?
• Can the problem be avoided rather than solved directly?

Lateral thinking is especially useful during solution generation, but proposed ideas must still be evaluated for feasibility, cost, security and correctness.

6.4 Means-End Analysis

The method repeatedly asks:

1. Where am I now?
2. Where do I need to be?
3. What is the important difference?
4. What action can reduce that difference?
5. What new subproblem must be solved before that action can be taken?

6.5 Subgoals in Means-End Analysis

Complex goals are often reached through a sequence of intermediate goals called subgoals.

The advantage of subgoals is that progress can be measured. Instead of facing one large vague goal, the solver works toward smaller clearly defined states.

6.6 Method of Focal Object

The method attempts to break habitual patterns of thinking. The selected problem or product becomes the focal object, and unrelated attributes are transferred to it to stimulate new ideas.

6.7 Applying the Focal-Object Method

A simple procedure is:

1. Select the focal object.
2. Select one or more unrelated objects.
3. List important attributes of the unrelated objects.
4. Combine those attributes with the focal object.
5. Interpret the combinations creatively.
6. Evaluate useful ideas.

The resulting ideas are not accepted automatically. The purpose is to generate possibilities that ordinary linear reasoning might not produce.

6.8 Morphological Analysis

This technique is useful when a design problem contains several independent choices.

6.9 Constructing a Morphological Matrix

A morphological matrix organizes alternatives into categories.

Possible solutions can be generated by selecting one option from each dimension. For example:

SMS + Immediate + Urgent + One Student

or:

Portal Alert + Daily + Normal + Department

Not every combination will be sensible. Morphological analysis generates possibilities; evaluation identifies combinations that are practical and useful.

6.10 Research as a Problem-Solving Technique

Effective problem solvers do not assume they must invent every solution from the beginning. Existing knowledge can prevent wasted effort and reveal tested methods.

Research may involve:

• textbooks;
• technical documentation;
• standards;
• scholarly articles;
• official manuals;
• existing software designs;
• reliable technical communities;
• experiments and measurements.

6.11 Effective Technical Research

Technical research should be purposeful. Searching randomly for information can produce large amounts of irrelevant material.

A useful process is:

1. Define the exact question.
2. Identify likely authoritative sources.
3. Search using specific terminology.
4. Compare multiple reliable sources where necessary.
5. Check whether the information is current enough for the topic.
6. Test technical recommendations before relying on them in production.

6.12 Root Cause Analysis

Solving only a symptom may allow the problem to return.

6.13 The Five Whys Technique

The number five is not a rigid requirement. The objective is to continue questioning until the relevant underlying cause has been identified sufficiently for action.

6.14 Cause-and-Effect Reasoning

Complex problems may have several contributing causes rather than one root cause.

A cause-and-effect analysis groups possible causes into categories so that the investigation does not focus too narrowly.

This form of analysis encourages a broad investigation before conclusions are drawn.

6.15 Proof as a Problem-Solving Technique

Proof is important in computing because some claims must be established logically rather than tested only through examples.

Testing many examples can support confidence but does not replace a general proof when proof is required.

6.16 Direct Proof and Counterexample

Direct Proof:

A direct proof begins with accepted facts or assumptions and logically derives the required conclusion.

Counterexample:

Counterexamples are powerful in algorithm design. If a developer claims that an algorithm works for all valid inputs, finding one valid input for which it fails disproves that claim.

6.17 Divide and Conquer

The basic pattern is:

1. Divide: Break the original problem into smaller subproblems.
2. Conquer: Solve the subproblems.
3. Combine: Merge the partial solutions.

6.18 Divide and Conquer in Computing

Divide-and-conquer methods appear in many important algorithms.

Binary Search:

Binary search finds a target value in a sorted collection by repeatedly dividing the search region into halves.

Merge Sort:

Merge sort divides a collection into smaller parts, sorts the parts and combines the sorted results.

Difference from Ordinary Decomposition:

General decomposition divides a complex system into manageable parts. Divide and conquer is more specific: the subproblems are typically structured so that the same general solution method can be applied repeatedly, and their results are combined.

6.19 Comparing Problem-Solving Techniques

6.20 Combining Techniques in Complex Problems

Complex problems rarely fit one method perfectly.

6.21 Applied Problem-Solving Case Studies

Case Study 1: Duplicate Student Records:

Case Study 2: Designing a Course Recommendation Feature:

Case Study 3: Searching a Sorted Student List:

After analysing a problem and determining the logical steps required for its solution, the solution must often be represented in a form that can be examined before programming begins. One important representation is the flowchart.

A flowchart presents the logical flow of a solution graphically. Instead of describing every operation entirely in sentences, it uses standardized shapes connected by directional lines. This allows the student to see the order in which operations occur, where decisions are made, and where actions are repeated.

Flowcharts are particularly useful to beginning programmers because they make the structure of an algorithm visible. They can expose logical errors that may be less obvious in ordinary prose.

7.2 Meaning of a Flowchart

The word flow refers to the direction in which control moves through the solution. The chart therefore shows not merely what operations are required but also the order in which they are performed.

7.3 Purposes of Flowcharts

Flowcharts serve several purposes in problem solving and program development. They can be used to:

• plan the logic of a solution before coding;
• communicate an algorithm visually;
• identify missing or unnecessary operations;
• show alternative paths through decisions;
• represent repeated operations clearly;
• support debugging and logical verification;
• provide documentation for an existing process or program.

A flowchart should not be treated merely as a drawing exercise. Its real purpose is to represent logic accurately.

7.4 Basic Flowchart Symbols

Different symbols represent different categories of operations. The most important symbols at introductory level are shown below.

7.5 Rules for Constructing Flowcharts

A well-constructed flowchart should communicate the algorithm without unnecessary ambiguity. Useful conventions include the following:

• Provide a clearly identifiable starting point and ending point.
• Use the correct symbol for each type of operation.
• Connect symbols using directional flow lines.
• Label alternative decision branches appropriately, commonly Yes/No or True/False.
• Keep the direction of flow consistent wherever practical.
• Avoid crossing lines unnecessarily.
• Ensure every path leads logically to another operation or termination.
• Keep the text inside symbols concise but meaningful.

7.6 Sequence in Flowcharts

A sequence is the simplest control structure. Operations are performed one after another without branching.

7.7 Selection in Flowcharts

Selection introduces alternative paths. A condition is evaluated, and the result determines which branch of the flowchart is followed.

A decision must be expressed as a condition that can be evaluated. Examples include:

• Age ≥ 18?
• Balance ≥ Withdrawal?
• Password correct?
• Number MOD 2 = 0?
• Temperature > 30?

7.8 Multiple Selection

Some problems require more than two possible outcomes. Such problems can be represented using a sequence of decisions.

The order of the tests matters. When ranges are tested from the highest boundary downward, a score of 75 satisfies the first condition immediately and need not be compared with lower boundaries.

7.9 Repetition in Flowcharts

Repetition occurs when control returns to an earlier point so that one or more operations are performed again.

A repetition structure must contain some mechanism that eventually changes the condition. Otherwise, the process may continue indefinitely.

7.10 Flowchart for Arithmetic Problems

7.11 Flowchart for Comparison Problems

7.12 Flowchart for Validation Problems

Validation checks whether data satisfies defined rules before it is accepted for processing.

Validation is important because even a mathematically correct algorithm can produce meaningless results when inappropriate data is accepted.

7.13 Flowchart for Accumulation and Counting

Two common repetitive operations are counting and accumulation.

A counter records how many times an event has occurred. An accumulator maintains a running total.

7.14 Nested Decisions

A decision may occur inside another decision. This structure is called a nested decision.

7.15 Developing a Flowchart from a Problem Statement

A reliable procedure is to move from the problem statement to a flowchart in stages.

1. Identify the required result.
2. Identify the input data.
3. Determine the processing operations.
4. Identify decisions and their possible outcomes.
5. Identify repeated operations.
6. Arrange the operations logically.
7. Draw the appropriate symbols and connections.
8. Trace the flowchart with sample data.

7.16 Tracing a Flowchart

Tracing means following the flowchart manually using selected values and recording the changes that occur.

7.17 Advantages and Limitations of Flowcharts

Advantages:

• They provide a visual representation of logic.
• They make decisions and repetitions easy to identify.
• They can improve communication between developers and learners.
• They assist in detecting logical omissions.
• They provide useful documentation.

Limitations:

• Large programs can produce very large and complicated flowcharts.
• Changing complex flowcharts may require substantial redrawing.
• They may become difficult to follow when too many connectors and branches are present.
• They do not directly express all programming-language details.

7.18 From Flowchart to Program

A flowchart provides a language-independent representation of program logic. Each major flowchart structure has a corresponding programming structure.

A student who understands the logic represented by a flowchart is therefore well prepared to express the same solution in pseudocode and subsequently in a programming language.

A flowchart expresses solution logic graphically. Pseudocode expresses the same type of logic textually using structured, programming-like statements that are intended primarily for human understanding.

Pseudocode is especially useful because it allows a problem solver to develop programming logic without being distracted by the exact syntax of Python, C or another language. Once the logic has been established, translation into a programming language becomes more systematic.

8.2 Meaning of Pseudocode

Consider an algorithm for calculating the square of a number:

The logic is clear even though the statements are not required to follow the exact syntax of C or Python.

8.3 Characteristics of Good Pseudocode

Good pseudocode should be:

• clear: each instruction should have an obvious meaning;
• ordered: statements should appear in their intended execution sequence;
• consistent: similar operations should use similar notation;
• structured: decisions and repetitions should be visibly organized;
• language-independent: unnecessary dependence on a particular programming language should be avoided;
• complete: the major logical operations needed to solve the problem should be present.

The improved version makes the required data and operation explicit.

8.4 Pseudocode and Programming Languages

Pseudocode resembles programming code but should not be confused with executable code.

8.5 Variables and Assignment Statements

Examples of meaningful variable names include:

• score
• total
• average
• quantity
• balance
• student_count

An assignment gives a value to a variable.

The statement count = count + 1 should be interpreted operationally: obtain the current value of count, add 1, and store the result back in count.

8.6 Input and Output Statements

Input statements obtain data required by the algorithm. Output statements communicate results.

Other pseudocode conventions may use words such as INPUT, GET, PRINT, WRITE or OUTPUT. Consistency and clarity are more important than adopting one universal keyword because pseudocode has no single official syntax.

8.7 Arithmetic Expressions

Arithmetic expressions combine values and operators to produce numerical results.

8.8 Relational and Logical Conditions

Conditions are used to make decisions. A relational condition compares values.

Logical operators combine conditions.

8.9 Sequence in Pseudocode

Sequence means executing statements in the order in which they appear.

8.10 IF Statements

An IF statement performs an action only when a specified condition is true.

8.11 IF-ELSE Statements

An IF-ELSE structure chooses between two alternatives.

8.12 Multiple and Nested Decisions

Multiple alternatives may be represented using ELSE IF statements.

A decision can also occur inside another decision.

8.13 Repetition Using WHILE

A WHILE structure repeats statements as long as its condition remains true.

8.14 Count-Controlled Repetition

Count-controlled repetition is appropriate when the required number of repetitions is known.

8.15 Accumulators and Counters

8.16 Sentinel-Controlled Repetition

Sentinel-controlled repetition is useful when the number of data items is not known in advance.

8.17 Data Validation in Pseudocode

Pseudocode can express validation before data is used.

Notice that validation is not merely an error message. The algorithm must specify what happens after invalid data is detected.

8.18 Developing Pseudocode from a Problem

The development of pseudocode should begin with analysis rather than immediate writing.

8.19 Tracing Pseudocode

A trace table records the values of variables as an algorithm executes. It is particularly useful for checking loops and decisions.

Tracing is especially valuable for identifying:

• incorrect initial values;
• conditions that stop too early or too late;
• counters that are not updated;
• incorrect accumulation;
• wrong decision branches.

8.20 Flowcharts and Pseudocode Compared

Neither representation is universally superior. A flowchart can make branching easier to visualize, while pseudocode can express a detailed algorithm more compactly. Both are tools for solution design.

8.21 From Pseudocode to Programming Code

One major advantage of pseudocode is that its structures correspond closely to programming constructs.

Before translation, the pseudocode should be tested logically. Programming code should not be used as a substitute for understanding the problem. If the underlying logic is incorrect, translating it accurately into a programming language merely produces a program that implements the wrong solution.

Many computing problems require a solution to choose an action from several alternatives. Such problems are called decision-oriented problems. The final result depends not merely on a calculation but on the combination of conditions that apply.

Simple decisions can be represented adequately with an IF statement or a decision symbol in a flowchart. As the number of conditions increases, however, the logic may become difficult to understand. Two useful tools for organizing such logic are decision tables and decision trees.

A decision table organizes conditions and actions in tabular form. A decision tree represents the same general type of logic as a branching structure. Both techniques help the problem solver examine whether all important combinations have been considered.

9.2 Decision-Oriented Problems

A decision-oriented problem contains one or more conditions whose values determine what action should be taken.

Other examples include:

• determining whether a bank transaction should be approved;
• deciding whether a student is eligible for a course;
• determining shipping charges according to location and weight;
• assigning a discount according to customer type and purchase amount;
• deciding whether a user may access a protected resource;
• determining whether a registration record is complete.

The complexity increases when several conditions must be considered together.

9.3 Meaning of a Decision Table

Decision tables are especially useful when several conditions interact. Instead of tracing nested IF statements mentally, the problem solver can inspect the combinations systematically.

9.4 Components of a Decision Table

A typical decision table contains four important elements:

• condition statements — the factors being tested;
• condition entries — the values or states of those factors;
• action statements — the possible actions;
• action entries — indicators showing which actions apply under each rule.

Each column of condition and action entries normally represents one rule.

9.5 Constructing a Simple Decision Table

Suppose a student is permitted to enter an examination hall only if the student has a valid examination card.

The table contains two possible cases: the condition is true or false. Each case produces a different action.

9.6 Decision Tables with Multiple Conditions

Suppose an online examination requires both a registered account and a valid examination authorization.

There are two conditions, each with two possible values. This gives four possible combinations.

The table makes an important rule immediately visible: access is permitted only when both conditions are satisfied.

9.7 Rules in Decision Tables

If there are n independent conditions and each condition has exactly two possible values, a complete table may contain up to:

2ⁿ possible combinations.

This explains why decision tables can become large when many conditions are included. However, some combinations may be impossible or may lead to exactly the same action and can sometimes be simplified.

9.8 Complete and Reduced Decision Tables

Complete Decision Table:

A complete decision table explicitly represents every relevant combination of condition values.

Reduced Decision Table:

A reduced decision table combines rules when some condition does not affect the outcome.

The dash means that the value of the password condition does not matter when the account is locked.

9.9 Validating a Decision Table

A decision table should be checked carefully before implementation.

Important questions include:

• Have all relevant conditions been included?
• Are all meaningful combinations represented?
• Does each rule produce the required action?
• Are any rules contradictory?
• Are impossible combinations being treated as though they were valid?
• Can some rules be combined without changing the logic?

9.10 Meaning of a Decision Tree

Decision trees display the order in which conditions are examined. This makes them particularly useful when one decision determines whether another decision needs to be considered.

9.11 Components of a Decision Tree

A simple decision tree contains:

• root node — the first decision;
• decision nodes — conditions tested during the process;
• branches — possible outcomes of each decision;
• leaf or terminal nodes — final actions or conclusions.

9.12 Constructing a Decision Tree

A useful procedure is:

1. Identify the first relevant condition.
2. Create a branch for each possible result.
3. Determine whether another condition must be tested on each branch.
4. Continue branching until a final action is reached.
5. Check that all meaningful cases are represented.

9.13 Decision Trees with Multiple Conditions

Consider a simplified bank withdrawal rule:

• the PIN must be correct;
• the requested amount must be positive;
• the available balance must be sufficient.

The tree demonstrates that some conditions are evaluated only if earlier requirements are satisfied.

9.14 Order of Decisions

The order of conditions in a decision tree can affect clarity and efficiency even when the final logical result is the same.

Good decision ordering can:

• eliminate impossible paths early;
• avoid unnecessary processing;
• improve readability;
• reflect important business or security rules.

9.15 Decision Table and Decision Tree Compared

9.16 Translating Decision Tables into Pseudocode

Decision tables can be translated into conditional statements after the rules are understood.

The decision table helps establish the rule, while the pseudocode expresses the rule in algorithmic form.

9.17 Translating Decision Trees into Pseudocode

Decision trees frequently translate into nested IF structures.

The nested structure follows the same sequence of questions represented in the decision tree.

9.18 Applied Case Study: Student Result Classification

Suppose scores must be validated and classified according to the following simplified rules:

• Score below 0 or above 100: Invalid.
• 70–100: A.
• 60–69: B.
• 50–59: C.
• 45–49: D.
• 40–44: E.
• 0–39: F.

9.19 Applied Case Study: Loan Eligibility

Consider a simplified illustration in which a loan request may proceed only if:

• the applicant's account is active;
• the applicant satisfies the stated minimum income condition;
• the requested amount does not exceed an applicable limit.

The table shows that later conditions become irrelevant once an earlier mandatory requirement fails.

9.20 Choosing an Appropriate Solution Representation

Algorithms, flowcharts, pseudocode, decision tables and decision trees are complementary tools. The problem solver should select the representation that makes the logic easiest to understand and verify.

The earlier chapters have concentrated on understanding problems and designing solutions. Programming is the stage at which a designed solution is expressed in a formal language that a computer system can process.

A beginner may be tempted to start by memorizing programming commands. However, successful programming depends more fundamentally on clear problem analysis, correct algorithms and sound logical thinking. Programming syntax provides a way to express the solution; it does not replace the reasoning required to discover that solution.

This chapter introduces the essential concepts required to translate simple algorithms into programs, with illustrations in Python and C.

10.2 Meaning of Programming

Programming therefore involves more than typing code. A complete programming task may include:

• understanding the problem;
• designing the algorithm;
• choosing suitable data representations;
• writing source code;
• testing the program;
• correcting errors;
• improving the solution.

10.3 Programming Language

Examples include:

• C;
• Python;
• Java;
• C++;
• JavaScript;
• C#.

Programming languages differ in syntax and design philosophy, but fundamental ideas such as variables, expressions, conditions and repetition occur across many languages.

10.4 From Problem to Executable Program

A sound programming workflow can be represented as:

1. Define the problem.
2. Analyse inputs, outputs, rules and constraints.
3. Develop an algorithm.
4. Represent the algorithm using pseudocode or another design tool.
5. Translate the solution into source code.
6. Run or compile the program.
7. Test with selected inputs.
8. Debug and refine the program.

10.5 Source Code and Program Translation

A processor ultimately executes machine-level instructions. Therefore, source code must be translated or executed through an appropriate language implementation.

10.6 Compiler and Interpreter

Compiler:

C implementations commonly use compilation to produce executable machine code.

Interpreter:

Python programs are commonly executed through the Python runtime environment.

10.7 Syntax and Semantics

10.8 Variables

Examples include:

The value associated with a variable may change:

After the second statement, count has the value 6.

10.9 Constants and Literals

A constant represents a value that is intended not to change during a particular computation or program design.

10.10 Data Types

Common basic data types include:

The exact data types and their representation differ among languages.

10.11 Identifiers and Naming

Meaningful identifiers improve readability.

Naming rules differ among languages, but identifiers generally must follow the language's lexical rules and must not conflict improperly with reserved keywords.

10.12 Assignment Statements

Assignment stores or associates a value with a variable.

The equals symbol in an assignment does not necessarily express mathematical equality in the ordinary algebraic sense. It directs the program to evaluate the expression on the right and assign the result to the variable on the left.

10.13 Arithmetic Operators

10.14 Operator Precedence

Programming languages define rules that determine the order in which operations are evaluated.

Parentheses can make the intended order explicit:

Now the result is 20.

10.15 Expressions

Examples include:

Expressions may be arithmetic, relational or logical.

10.16 Input Statements

Programs often require values from users.

Python Input:

The input() function returns textual input. Numerical input usually requires conversion.

C Input:

In introductory C programs, scanf() can be used to obtain formatted input.

The %d conversion specification is used here for an integer.

10.17 Output Statements

Python Output:

C Output:

The specific syntax differs, but the underlying purpose is the same: communicate a result to the user.

10.18 Relational Operators

Relational operators compare values and produce a logical result.

10.19 Logical Operators

Logical operators combine or modify conditions.

10.20 Implementing Sequence in Python and C

Consider the algorithm:

Python:

C:

Although the syntax differs, the logical sequence is identical.

10.21 Worked Program: Rectangle Area

Python:

C:

10.22 Worked Program: Average Score

Python:

C:

10.23 Worked Program: Temperature Conversion

Python:

C:

10.24 Errors in Programs

Programs may fail in different ways. Understanding the type of error helps determine how it should be corrected.

Syntax Error:

A syntax error occurs when source code violates the grammar of the programming language.

Runtime Error:

A runtime error occurs while the program is executing.

Logical Error:

10.25 Testing and Debugging

Testing should include more than one convenient example.

Debugging by Tracing:

Suppose a program calculates the wrong average. The programmer can inspect:

• the input values;
• the calculated total;
• the number used as the divisor;
• the final average.

This mirrors the algorithm-tracing methods used before programming and demonstrates why careful algorithm design remains useful during debugging.

10.26 Relationship Between Algorithm, Pseudocode and Program

The relationship among these concepts can be summarized as follows.

Most useful programs do more than execute a fixed sequence of statements. They make decisions and repeat operations. A banking application decides whether a withdrawal should be approved. A result-processing system assigns different grades to different scores. A payroll system repeatedly processes many employees. A search program examines data until the required item is found or the available data is exhausted.

The two programming ideas that make these behaviours possible are selection and repetition. Selection allows the program to choose among alternative actions. Repetition allows one or more statements to be executed repeatedly under controlled conditions.

These concepts were introduced earlier through algorithms, flowcharts and pseudocode. This chapter now develops them as actual programming logic using Python and C.

11.2 Control Structures in Programming

Three fundamental control structures are:

• Sequence — statements execute one after another.
• Selection — one path is chosen according to a condition.
• Repetition — statements are executed repeatedly.

A large proportion of introductory programming problems can be solved by combining these three structures appropriately.

11.3 Boolean Expressions

Examples include:

The result of each expression depends on the current values of the variables involved.

11.4 Relational and Logical Operators

Relational operators compare values.

Logical operators combine conditions.

11.5 Simple Selection

Simple selection performs an action only when a condition is true.

Python:

C:

If the condition is false, the controlled statement is skipped.

11.6 Two-Way Selection

Two-way selection chooses between two alternatives.

For score = 67, the output is Pass. For score = 28, the output is Fail.

11.7 Multiple Selection

Multiple selection is required when several possible outcomes exist.

Python uses elif to represent additional alternatives after the first IF condition.

C Version:

Conditions should be ordered carefully. Testing score ≥ 40 before score ≥ 70 would cause a score of 80 to satisfy the lower condition too early if the logic were structured incorrectly.

11.8 Nested Selection

11.9 Compound Conditions

Sometimes several conditions must be true at the same time.

The AND operator requires both conditions to be true.

An OR condition requires at least one of its component conditions to be true.

11.10 Selection in Python

Python uses indentation to indicate the statements that belong to an IF, ELIF or ELSE block.

11.11 Selection in C

C usually uses braces to group statements belonging to a control structure.

Although braces may sometimes be omitted for a single controlled statement, using braces consistently can improve clarity for beginners.

11.12 Introduction to Repetition

Without repetition, processing one hundred students might require one hundred copies of the same statements. Loops allow the repeated operation to be written once and controlled systematically.

Repetition may be:

• count-controlled;
• condition-controlled;
• sentinel-controlled.

11.13 Count-Controlled Repetition

Count-controlled repetition is appropriate when the number of required iterations is known.

11.14 Condition-Controlled Repetition

A condition-controlled loop continues while a condition remains true.

The update statement is essential. If count never changes, the condition may remain true indefinitely.

11.15 Sentinel-Controlled Repetition

A sentinel value indicates the end of data when the number of entries is not known beforehand.

If the user enters 20, 15, 30 and then -1:

Total = 20 + 15 + 30 = 65.

11.16 The FOR Loop

A FOR loop is particularly suitable when iterating over a known range or collection.

Python:

The call range(1, 11) produces values beginning at 1 and ending before 11, giving 1 through 10.

C:

The C FOR statement contains initialization, condition and update expressions.

11.17 The WHILE Loop

A WHILE loop checks its condition before each iteration.

11.18 Nested Loops

Nested loops are useful when a repeated operation itself contains another repeated operation.

For each value of row, the inner loop completes all three column values.

11.19 Counters and Accumulators

Counters and accumulators are fundamental in repetitive programs.

11.20 Input Validation Using Loops

A program should not always accept the first input blindly. A loop can repeatedly request input until an acceptable value is supplied.

If the first value is 120, the program rejects it and requests another value. If the next value is 78, it is accepted.

C Version:

11.21 Combining Selection and Repetition

Real programs frequently make a decision during each iteration.

The loop repeats the processing five times, while the IF statement classifies each score.

11.22 Worked Program: Grade Classification

Python Solution:

C Solution:

11.23 Worked Program: Sum and Average of Scores

Python Solution:

C Solution:

11.24 Worked Program: Multiplication Table

Python Solution:

C Solution:

11.25 Tracing Program Logic

Tracing remains useful after an algorithm has been converted to code. The programmer can follow variable values through the program and compare actual behaviour with expected behaviour.

The purpose of programming in a problem-solving course is not simply to memorize commands. The real objective is to convert a clearly defined problem into a reliable computational solution. The programmer should understand the problem, identify the required data, design the algorithm, represent the logic clearly, implement the algorithm, test the program and refine the solution where necessary.

This chapter integrates the major ideas developed throughout the course. The examples demonstrate the complete path from problem statement to working program using Python and C.

12.2 The Complete Problem-Solving Cycle

A disciplined programming solution may follow the stages below:

1. Identify the problem.
2. Define the expected result.
3. Analyse inputs, outputs, requirements and constraints.
4. Develop the algorithm.
5. Represent the solution using pseudocode, flowchart or another suitable design tool.
6. Translate the solution into a programming language.
7. Compile or execute the program.
8. Test the program using suitable data.
9. Debug defects.
10. Evaluate whether the program satisfies the original problem.
11. Refine the solution where necessary.

These stages are not always strictly linear. Testing may reveal that the original algorithm was incomplete, requiring the programmer to return to an earlier stage.

12.3 Translating a Problem into a Program

A programmer should not translate the problem statement directly into code without analysis. The task should first be reduced to precise computational requirements.

The program becomes easier to write after these elements have been identified.

12.4 Developing a Program from an Algorithm

Python:

C:

12.5 Program Testing Strategy

Testing should be planned. A program that produces the correct result for one example has not necessarily been tested adequately.

Useful test categories include:

• normal data;
• boundary data;
• invalid data;
• special cases.

12.6 Debugging and Refinement

Debugging should be systematic rather than based on random changes.

A useful debugging process is:

1. Observe the incorrect behaviour.
2. Identify the smallest part of the program that may be responsible.
3. Form a hypothesis about the defect.
4. Inspect variable values or intermediate results.
5. Correct one identified problem.
6. Test again.
7. Confirm that the correction did not introduce another defect.

12.7 Practical Program: Simple Calculator

Python:

C:

12.8 Practical Program: Even or Odd Number

Python:

C:

12.9 Practical Program: Largest of Three Numbers

Algorithm:

Python:

C:

12.10 Practical Program: Student Result Processor

Python:

12.11 Practical Program: Simple Interest Calculator

Python:

C:

12.12 Practical Program: Sum of Integers

Python:

C:

12.13 Practical Program: Factorial

For example:

Python:

C:

12.14 Practical Program: Prime Number Test

To determine whether n is prime, a simple introductory algorithm can test whether any integer from 2 up to n − 1 divides n exactly. A more efficient elementary version needs to test divisors only up to the square root of n.

Python:

12.15 Practical Program: Searching a List

Searching is a fundamental computing problem. One simple method is linear search, which examines items one after another until the target is found or the collection ends.

Python:

C:

12.16 Practical Program: Menu-Driven Application

A menu-driven program allows the user to select an operation from a displayed list.

The menu converts one general program into several selectable operations.

12.17 Functions and Problem Decomposition

Functions support problem decomposition by allowing a large problem to be divided into smaller tasks.

Each function can be developed and tested separately.

12.18 Python Functions

Python defines a function using the def keyword.

The function receives one parameter, calculates the square and returns the result.

Function for Average:

The result is 70.

12.19 C Functions

C also supports functions.

The square function can be reused whenever the program needs to calculate a square.

12.20 Input Validation and Defensive Programming

Examples include:

• checking score ranges before grading;
• preventing division by zero;
• checking that quantities are not negative;
• checking that required values are supplied;
• checking that menu choices are valid.

12.21 Testing with Normal, Boundary and Invalid Data

A reliable test strategy should deliberately include different categories of input.

12.22 Comparing Python and C Solutions

Python and C can implement the same algorithm even though their syntax and execution models differ.

12.23 Program Evaluation and Refinement

A program should be evaluated against the original problem rather than judged only by whether it runs.

Evaluation questions include:

• Does the program produce the correct result?
• Does it handle required boundary cases?
• Does it reject invalid input where necessary?
• Is the code understandable?
• Is unnecessary repetition present?
• Can the program be divided into clearer functions?
• Does the output communicate results clearly?
• Does the program satisfy the original requirements?

12.24 Integrating the Problem-Solving Process

The central ideas of this course can now be combined into one complete example.

This example combines nearly every important idea developed in the course: problem identification, requirements, constraints, algorithm design, pseudocode, validation, repetition, selection, counters, accumulators, programming, testing and evaluation.