~/Introduction to Problem Solving

4.1 The Five Steps of Problem Solving

Every programming task — from a 3-line print statement to a banking application — follows the same five steps:

4.1.1 Step 1 — Analysing the Problem

Read the problem statement several times. Ask yourself three essential questions:

• Input — What data does the program receive? In what form?
• Output — What must the program produce?
• Processing — What calculation or decision turns the input into the output? Are there any constraints (e.g., "the number must be positive")?

4.1.2 Step 2 — Developing an Algorithm

Write the sequence of steps that transform the input into the output. Keep the steps language-independent — plain English is fine. You will express this algorithm either as a flowchart or as pseudocode (covered in §4.3 and §4.4).

4.1.3 Step 3 — Coding

Translate each step of the algorithm into real Python (or any chosen language). Use clear variable names, follow indentation rules, and add comments that explain why a piece of code exists, not what it does (well-named variables already say that).

4.1.4 Step 4 — Testing

Run the code on carefully chosen sample inputs — not only the "happy path", but also edge cases: zero, negative numbers, very large numbers, empty strings, wrong types. Verify the output against what you computed by hand.

4.1.5 Step 5 — Debugging

If an output is wrong (or the program crashes), debugging is the detective work of finding and fixing the cause. Common techniques:

• Add print() statements to see intermediate values.
• Read the error message carefully — it usually names the line and the problem.
• Re-check the algorithm for a logic mistake, not just the syntax.

Once the fix is applied, go back to Test with more inputs. The cycle Code → Test → Debug repeats until the program is correct.

4.2 What is an Algorithm?

4.2.1 Characteristics of a Good Algorithm

Step 1: Start
Step 2: Read length L and breadth B
Step 3: Compute Area = L × B
Step 4: Print Area
Step 5: Stop

4.3 Representing an Algorithm — Flowcharts

A flowchart is a pictorial representation of an algorithm using a small set of standard shapes connected by arrows. It is the easiest way to visualise how control moves through a program — especially when conditions and loops are involved.

4.3.1 Standard Flowchart Symbols

4.3.2 Flowchart — With a Decision

Decisions are where flowcharts really shine. The diamond has one entry and two exits (yes / no).

4.4 Representing an Algorithm — Pseudocode

Pseudocode is a way of describing an algorithm using structured English that looks like code but is not bound by any real language's syntax. It is quicker to write than a flowchart and easier to convert into Python.

4.4.1 Pseudocode Conventions

• Use capitalised keywords — INPUT, OUTPUT, IF … THEN … ELSE, WHILE, FOR, END.
• Use plain English where convenient — "read a number", "compute area".
• Use indentation to show which statements belong inside an IF or a loop.
• No semicolons, no braces, no specific operators — readability comes first.

BEGIN
    INPUT L, B
    SET A ← L × B
    OUTPUT A
END

BEGIN
    INPUT N
    IF N > 0 THEN
        OUTPUT "Positive"
    ELSE IF N = 0 THEN
        OUTPUT "Zero"
    ELSE
        OUTPUT "Negative"
    ENDIF
END

4.4.2 Flowchart vs. Pseudocode — When to use Which

4.5 Decomposition

Think of decomposition as how you'd answer the question "How do you cook a full thali?" — you don't answer in one breath; you break it down: cook rice, cook dal, cook sabzi, make chapatis, make salad. Each of those is itself a mini-problem with its own steps. The same idea applies to programs.

4.5.1 Example — Build a Student Report-Card Program

"Write a program to generate report cards for a class of students" sounds intimidating. But after decomposition:

4.5.2 Benefits of Decomposition

• Easier to think about — you focus on one piece at a time.
• Easier to test — each sub-problem can be tested independently.
• Easier to reuse — a well-written "compute grade" function can be dropped into the next project.
• Easier to share work — different team members can solve different sub-problems in parallel.
• Easier to debug — when something breaks, you know which piece to look at.