Introduction to Problem Solving

A computer is fast and it is exact, but it has no common sense. Tell a friend "book my ticket on IRCTC" and they will fill in a hundred small decisions on their own — which train, which class, which date. Tell a computer the same thing and it fills in nothing. It does exactly what the instructions say, in exactly the order they are written, every single time. So the hard part of programming is not typing Python. The hard part is working out the complete, unambiguous list of steps before you type anything.

CBSE splits that work into five steps.

Steps 4 and 5 loop back into step 3, and sometimes all the way back to step 1. If testing shows the algorithm itself was wrong, no amount of fiddling with the code will save it.

Step 1 in detail. Analysing a problem means answering three questions before you write a single line:

• Input — what data is given to me, and in what form?
• Process — what has to be done to that data?
• Output — what exactly has to be shown, and in what form?

Two more questions save you most of the pain later. What are the constraints (marks lie between 0 and 100, an age cannot be negative), and what are the edge cases (zero students, all marks equal, a bill of exactly ₹1000)?

Worked example. Problem: a student wrote five unit tests. Print the total, the average, and PASS if the average is 33 or more, otherwise FAIL.

marks = [72, 65, 88, 54, 91]       # INPUT
total = sum(marks)                 # PROCESS
average = total / len(marks)
if average >= 33:
    result = "PASS"
else:
    result = "FAIL"
print("Total   :", total)          # OUTPUT
print("Average :", average)
print("Result  :", result)

Real output:

Total   : 370
Average : 74.0
Result  : PASS

Why the analysis step is not optional. Suppose the student was absent for every test, so the list is empty. The same "process" now blows up:

marks = []                 # the student was absent for every test
average = sum(marks) / len(marks)
print(average)

Real output:

Traceback (most recent call last):
  File "avg.py", line 2, in 
    average = sum(marks) / len(marks)
              ~~~~~~~~~~~^~~~~~~~~~~~
ZeroDivisionError: division by zero

Nothing is wrong with the Python here. The analysis was incomplete — nobody ever decided what an empty list should mean. That decision belongs in step 1, not in step 5.

The computer follows order, not intention. Statements run top to bottom, and a name must exist before it is used.

total = price * qty      # used before they exist
price = 60
qty = 3
print(total)

Real output:

Traceback (most recent call last):
  File "order.py", line 1, in 
    total = price * qty      # used before they exist
            ^^^^^
NameError: name 'price' is not defined. Did you mean: 'print'?

You and I can read those three lines and see what was meant. Python cannot. It reaches line 1, looks for price, finds nothing, and stops. Ordering the steps correctly is part of the algorithm, not an afterthought.

An algorithm is a finite sequence of well-defined steps that solves a problem. The word comes from the name of the 9th-century mathematician al-Khwarizmi. An algorithm is not Python and not any other language — it is the plan. The same algorithm for finding the largest of three numbers works whether you finally write it in Python, in C++, or carry it out with a pencil.

The five characteristics of a valid algorithm. These are exam favourites, so learn the failure column as well as the definition.

Pseudocode is an algorithm written in structured English. No computer runs it, so no compiler will catch a mistake — the discipline has to come from you. There is no single official standard, so pick a set of keywords and stay consistent for the whole answer. These are the ones used throughout this chapter.

Two rows there deserve a second look, because they are where pseudocode and Python quietly disagree. MOD and DIV become % and // when you code them. But // in this pseudocode starts a comment, while // in Python is floor division. Same two characters, opposite meanings — keep track of which language you are currently writing in.

Worked example 1 — largest of three numbers (selection).

BEGIN
    READ a, b, c
    IF a >= b AND a >= c THEN
        SET largest = a
    ELSE IF b >= c THEN
        SET largest = b
    ELSE
        SET largest = c
    ENDIF
    PRINT largest
END

The same algorithm coded in Python:

a, b, c = 47, 92, 92

if a >= b and a >= c:
    largest = a
elif b >= c:
    largest = b
else:
    largest = c

print("a =", a, " b =", b, " c =", c)
print("Largest =", largest)

Real output:

a = 47  b = 92  c = 92
Largest = 92

Two things worth noticing. The second test compares only b with c — if the first test failed, then a was not greater than or equal to both of the others, so a cannot be the largest and re-testing it would be wasted work. And >= is used instead of > so that ties are handled: 47, 92, 92 must still report 92 rather than falling through every branch. Deliberately testing with equal values is exactly the edge-case thinking from step 1.

Worked example 2 — sum of the first n natural numbers (iteration).

BEGIN
    READ n
    SET total = 0
    SET i = 1
    WHILE i <= n DO
        SET total = total + i
        SET i = i + 1
    ENDWHILE
    PRINT total
END

In Python, with an extra print inside the loop so you can watch the algorithm work:

n = 5
total = 0
i = 1
while i <= n:
    total = total + i
    print("i =", i, "-> total =", total)
    i = i + 1
print("Sum of first", n, "natural numbers =", total)

Real output:

i = 1 -> total = 1
i = 2 -> total = 3
i = 3 -> total = 6
i = 4 -> total = 10
i = 5 -> total = 15
Sum of first 5 natural numbers = 15

Breaking finiteness. Delete one line — the one that changes i — and it stops being an algorithm at all:

SET total = 0
SET i = 1
WHILE i <= n DO
    SET total = total + i      // i is never changed
ENDWHILE

The condition i <= n is true on the first check and stays true forever, so the steps never end. Every loop needs three things: a starting value, a condition, and something inside the body that eventually makes the condition false. If you cannot point to all three, the loop is broken.

A flowchart is an algorithm drawn as boxes joined by arrows. Pseudocode is faster to write; a flowchart is far easier to see, especially when the logic branches. CBSE expects you to know the standard symbols and to be able to convert freely between flowchart, pseudocode and Python.

Four rules the examiner checks: exactly one START, at least one STOP, every decision has both exits labelled Yes and No, and every arrow points in one direction only. Since this page cannot draw real shapes, the charts below use text boxes and name the shape in a comment. On your answer sheet, draw the real shapes.

The three control structures. Everything you write this year is built from just these three patterns.

1. Sequence — one step after another, no choices.

   ( START )        oval
       |
  / READ n /        parallelogram
       |
  [ sq = n * n ]    rectangle
       |
  / PRINT sq /      parallelogram
       |
   ( STOP )         oval

2. Selection — the path splits and then rejoins.

            |
            v
   +--------------------+
   |  is marks >= 33 ?  |   diamond
   +--------------------+
      | Yes        | No
      v            v
  [ PRINT     ]  [ PRINT     ]
  [ "PASS"    ]  [ "FAIL"    ]
      |            |
      +-----+------+
            |
            v

3. Iteration — an arrow goes back up, and the decision is the only way out.

   [ SET i = 1 ]
         |
         v
   +--------------------+   No
+->|  is i <= 10 ?      |--------> exit loop
|  +--------------------+
|        | Yes
|        v
|  [ PRINT i ]
|        |
|        v
|  [ SET i = i + 1 ]
|        |
+--------+

Worked example 1 — leap year (nested selection). A year is a leap year if it is divisible by 400; otherwise, if it is divisible by 100 it is not; otherwise, if it is divisible by 4 it is; otherwise it is not.

          +-------------------+
          |      START        |   oval
          +-------------------+
                    |
                    v
          / READ year /            parallelogram
                    |
                    v
          +-------------------+
          | year MOD 400 = 0 ?|   diamond
          +-------------------+
             | Yes      | No
             |          v
             |   +-------------------+
             |   | year MOD 100 = 0 ?|   diamond
             |   +-------------------+
             |      | Yes      | No
             |      |          v
             |      |   +------------------+
             |      |   | year MOD 4 = 0 ? |   diamond
             |      |   +------------------+
             |      |      | Yes     | No
             v      v      v         v
         [leap=  ][leap=  ][leap=  ][leap=  ]
         [ True  ][ False ][ True  ][ False ]
             |      |      |         |
             +------+---+--+---------+
                        |
                        v
              / PRINT leap /          parallelogram
                        |
                        v
                  (  STOP  )          oval

Coded in Python and run on four years chosen to hit every branch:

for year in [1900, 2000, 2023, 2024]:
    if year % 400 == 0:
        leap = True
    elif year % 100 == 0:
        leap = False
    elif year % 4 == 0:
        leap = True
    else:
        leap = False
    print(year, "-> leap year?", leap)

Real output:

1900 -> leap year? False
2000 -> leap year? True
2023 -> leap year? False
2024 -> leap year? True

The order of the diamonds is the whole algorithm. Test 400 first, because 2000 is divisible by 4, by 100 and by 400, and only the first matching test decides the answer. Swap the first two diamonds and 2000 wrongly comes out as False, a non-leap year.

Worked example 2 — multiplication table (iteration).

          +----------------+
          |     START      |          oval
          +----------------+
                   |
                   v
          / READ num /                parallelogram
                   |
                   v
          +----------------+
          |   SET i = 1    |          rectangle
          +----------------+
                   |
                   v
          +----------------+   No
       +->| is i <= 10 ?   |------+   diamond
       |  +----------------+      |
       |           | Yes          v
       |           v         (  STOP  )
       |  / PRINT num * i /
       |           |
       |           v
       |  +----------------+
       |  | SET i = i + 1  |
       |  +----------------+
       |           |
       +-----------+

num = 7
i = 1
while i <= 10:
    print(num, "x", i, "=", num * i)
    i = i + 1
print("Table over")

Real output:

7 x 1 = 7
7 x 2 = 14
7 x 3 = 21
7 x 4 = 28
7 x 5 = 35
7 x 6 = 42
7 x 7 = 49
7 x 8 = 56
7 x 9 = 63
7 x 10 = 70
Table over

Which one should you use?

Once the algorithm is settled, coding is mostly translation. Three habits make the debugging step short: meaningful names (total_marks, not t), one idea per line, and a comment wherever the reason for a line is not obvious from the line itself.

Three kinds of errors. This table is worth memorising in full.

Syntax error — real run.

price = 250
if price > 100
    print("Discount applies")

  File "bill.py", line 2
    if price > 100
                  ^
SyntaxError: expected ':'

Notice that the correct line 1 never ran either. A syntax error stops the whole file before execution begins.

Run-time error — real run.

age = "Rahul"
print(int(age) + 1)

Traceback (most recent call last):
  File "age.py", line 2, in 
    print(int(age) + 1)
          ~~~^^^^^
ValueError: invalid literal for int() with base 10: 'Rahul'

Read a traceback from the bottom up. The last line names the error, the line above shows the exact statement, and the arrows point at the guilty part of it.

Logical error — real run. This one is the reason testing exists.

marks = [40, 50, 60]
average = marks[0] + marks[1] + marks[2] / 3
print("Average =", average)

Average = 110.0

No error message, no traceback, a confident wrong answer. Python obeyed precedence and divided only 60 by 3, giving 40 + 50 + 20. The fix is one pair of brackets:

marks = [40, 50, 60]
average = (marks[0] + marks[1] + marks[2]) / 3
print("Average =", average)

Average = 50.0

Testing. Testing means running the program on inputs whose correct answer you already know, and comparing. Pick test cases from three groups:

• Normal values — an ordinary case from the middle of the range.
• Boundary values — exactly on the limit, and one step either side. Most bugs hide here.
• Invalid or special values — zero, negative numbers, empty input, text where a number was expected.

Take the rule: a shop gives 10% discount when the bill is more than ₹1000. The boundary is 1000, so test 999, 1000 and 1001.

# Rule: 10% discount only when the bill is MORE THAN 1000 rupees.
for bill in [999, 1000, 1001, 0]:
    if bill > 1000:
        payable = bill - bill * 0.10
    else:
        payable = bill
    print("bill =", bill, "-> payable =", payable)

Real output:

bill = 999 -> payable = 999
bill = 1000 -> payable = 1000
bill = 1001 -> payable = 900.9
bill = 0 -> payable = 0

If the programmer had written bill >= 1000, tests T1, T3 and T4 would still pass — only T2 changes, from 1000 to 900.0. That single case is the whole reason boundary values are non-negotiable.

Debugging with a dry run. A dry run (trace table) means executing the code in your head, one line at a time, writing down every variable after every step. Here the program is asked for the largest of five numbers:

nums = [12, 45, 7, 99, 3]
largest = nums[0]
for n in nums:
    if n > largest:
        largest = n
    print("n =", n, "-> largest so far =", largest)
print("Largest =", largest)

Real output:

n = 12 -> largest so far = 12
n = 45 -> largest so far = 45
n = 7 -> largest so far = 45
n = 99 -> largest so far = 99
n = 3 -> largest so far = 99
Largest = 99

Four debugging techniques worth having:

1. Dry run on paper with a trace table — the only method that works when there is no error message at all.
2. Extra print statements inside loops and branches, exactly as done above, then delete them once fixed.
3. Comment out a block to see whether the bug disappears, which narrows down where it lives.
4. Explain the code out loud, line by line, to a friend or an empty chair. You will usually catch the wrong line while saying it.

Nobody can hold a five-hundred-step problem in their head. Decomposition is the habit of breaking a large problem into smaller sub-problems, each small enough to be understood, solved and tested on its own, and then joining the solutions back together.

Four reasons it is worth the effort:

• Each small piece is easy to check, so a bug is trapped inside one piece instead of hiding in the whole program.
• Pieces can be reused. "Find the highest mark" is needed by the report card, the merit list and the topper announcement.
• Work can be split. Four students in a project team can take one sub-problem each.
• Changes stay local. If the grading rule changes, only the grading piece is touched.

Worked example — a class result report. "Print the result report for a section" is too big to attack directly. Decompose it:

import statistics
import math

# ---- Sub-problem 1: collect the data ----
names = ["Aarav", "Diya", "Kabir", "Meera", "Rohan"]
marks = [78, 91, 55, 91, 62]

# ---- Sub-problem 2: check the data is usable ----
print("Records match?", len(names) == len(marks))

# ---- Sub-problem 3: compute the statistics ----
highest = max(marks)
lowest = min(marks)
mean = statistics.mean(marks)
median = statistics.median(marks)
mode = statistics.mode(marks)

# ---- Sub-problem 4: present the report ----
print("Topper  :", names[marks.index(highest)], "with", highest)
print("Lowest  :", lowest)
print("Mean    :", mean)
print("Median  :", median)
print("Mode    :", mode)
print("Mean rounded up :", math.ceil(mean))

Real output:

Records match? True
Topper  : Diya with 91
Lowest  : 55
Mean    : 75.4
Median  : 78
Mode    : 91
Mean rounded up : 76

Each block can be tested by itself. If the topper line is wrong, you know the bug is in sub-problem 3 or 4 and never touch sub-problem 1.

Someone has already decomposed a lot for you. Built-in functions such as sum(), max(), len(), and modules such as math, random and statistics, are sub-problems that other programmers solved and packaged. Finding a square root is a genuine sub-problem — here it is solved by hand with the Babylonian method, then compared with the packaged version:

import math

n = 2
guess = 1.0
step = 1
while step <= 5:
    guess = (guess + n / guess) / 2
    print("step", step, "-> guess =", guess)
    step = step + 1

print("My answer   :", guess)
print("math.sqrt(2):", math.sqrt(n))

Real output:

step 1 -> guess = 1.5
step 2 -> guess = 1.4166666666666665
step 3 -> guess = 1.4142156862745097
step 4 -> guess = 1.4142135623746899
step 5 -> guess = 1.414213562373095
My answer   : 1.414213562373095
math.sqrt(2): 1.4142135623730951

Five lines of loop get to within one digit of math.sqrt, which is impressive. That last digit is worth understanding, though, because it is not impatience on the loop's part. Running the same loop for 6, 7 or 8 steps prints exactly the same value — the iteration has settled on a number it can no longer improve, and that number sits one tiny step below the closest value the computer can store for the square root of 2. math.sqrt is built to land on that closest value every time. So the packaged sub-problem here is not merely shorter than the hand-written one, it is also more accurate. Once a sub-problem is solved and trusted, you use the solved version and spend your thinking on the parts that are actually new.

Worked example — a dice experiment. "Throw a die ten times and summarise the result" decomposes into generate, then summarise:

import random
import statistics

random.seed(11)            # fixes the sequence so the result is repeatable

# Sub-problem 1: generate the throws
throws = []
count = 1
while count <= 10:
    throws.append(random.randint(1, 6))
    count = count + 1

# Sub-problem 2: summarise them
print("Throws  :", throws)
print("Highest :", max(throws))
print("Sixes   :", throws.count(6))
print("Mean    :", statistics.mean(throws))

Real output (identical on every run, because of the seed):

Throws  : [4, 5, 4, 4, 5, 5, 2, 2, 5, 4]
Highest : 5
Sixes   : 0
Mean    : 4

random.seed(11) is itself a testing tool. Random output cannot be tested, because you never know the expected answer; fixing the seed makes the sequence repeatable so the summarising half can be tested properly.

How to decompose in an exam answer. Write the main problem at the top, list its sub-problems as numbered steps, and beside each write its input and its output. If a sub-problem still needs more than about five or six steps to describe, break it again. In Class 12 you will learn how to package each sub-problem under a name of its own; for now, a clearly commented block of code per sub-problem is exactly the right structure.