Neural Sync Active

Week 12: Top-Down Design & Decision Trees

Registry Synced

Week 12: Top-Down Design & Decision Trees

3311 words

17 min read

2026-09-12

Reading compass

Now · TL;DR

Computational Thinking — Week 12: Top-Down Design & Decision Trees

IITM’s CT Week 12 covers Top-down approach, Bottom-up approach, Decision Tree, Numerical Prediction, Behaviour Analysis, and Classification.

TL;DR

Week 12 closes the course by combining problem decomposition with data-driven decision making.

The main split is:

Problem-solving structure

Top-down: start with the big problem and break it into smaller subproblems.
Bottom-up: build useful small components first and combine them into a larger solution.

Prediction / analysis structure

Decision tree: make a sequence of tests to reach an outcome.
Numerical prediction: predict a number.
Classification: predict a category.
Behaviour analysis: infer patterns or tendencies from observed actions/data.

The overall mental map is:

\boxed{ \text{Problem} \rightarrow \text{decompose/build} \rightarrow \text{observe data} \rightarrow \text{make decisions/predictions} }

1. Top-down approach

A top-down approach starts with the complete problem and repeatedly divides it into smaller pieces.

Conceptually:


text
Big problem
├── Subproblem A
├── Subproblem B
└── Subproblem C

Each subproblem can then be decomposed further.

2. Example: online shopping system

Start with:


text
Build an online shopping system

Break into:


text
User management
Product catalogue
Cart
Payment
Order tracking

Then break Payment into:


text
Validate order
Calculate amount
Select payment method
Process transaction
Record status

This is top-down decomposition.

3. Why top-down helps

A large problem may be too complex to solve directly.

Top-down reasoning asks:

What smaller problems would solve this larger problem?

It reduces cognitive load and creates structure.

4. Stepwise refinement

Top-down design often uses stepwise refinement.

Start vague:


text
process order

Refine:


text
validate customer
validate items
calculate total
collect payment
create shipment

Refine again until steps are concrete enough to implement.

5. Top-down and procedures

This connects directly to Week 3.

A large task can be expressed using procedures:


text
main():
    readData()
    validateData()
    analyseData()
    displayResult()

Each procedure solves one subproblem.

6. Top-down tree

A useful representation:


text
Solve Problem
├── Read Input
├── Process Input
│   ├── Filter
│   ├── Compute
│   └── Validate
└── Produce Output

Notice the hierarchical tree structure.

7. Bottom-up approach

A bottom-up approach starts with smaller, useful components and combines them into larger systems.

Conceptually:


text
small components
       ↓
larger modules
       ↓
complete system

8. Example

Suppose we already have components for:


text
sorting
searching
authentication
database access
payments

We combine them into:


text
e-commerce application

That is bottom-up construction.

9. Bottom-up reuse

Bottom-up design often benefits from reusable components.

For example:


text
Queue
Dictionary
Graph traversal
File reader

may already exist.

A larger algorithm can use them without rebuilding their internals.

10. Top-down vs bottom-up

Top-down	Bottom-up
Start with whole problem	Start with smaller components
Decompose	Compose
Ask "what subproblems?"	Ask "what can these components build?"
Architecture-first intuition	Component-first intuition

Neither is universally superior.

Real systems often use both.

11. Hybrid approach

A realistic workflow:

use top-down thinking to determine major modules
use existing bottom-up components to implement them

Example:


text
Top-down:
Need "user authentication"

Bottom-up:
Reuse password hashing + database + session components

So the two approaches complement each other.

Common mistake: top-down = execute from first line

No.

Top-down refers to design/decomposition, not simply execution order.

The idea is moving:

\text{high-level problem} \rightarrow \text{lower-level details}

Common mistake: bottom-up = reverse execution

Also no.

Bottom-up means assembling larger abstractions from smaller ones.

It is a design strategy, not "run the final line first."

14. Decision tree

A decision tree represents decision-making as a branching structure.

Each internal node asks a question.

Branches correspond to possible answers.

Leaves represent final decisions/outcomes.

Example:


text
            Age >= 18?
            /       \
          No         Yes
          |           |
       Minor       Has ID?
                   /    \
                 No      Yes
                 |        |
               Reject   Accept

15. Components of a decision tree

A decision tree has:

Root

Starting decision/test.

Internal node

Another condition/test.

Branch

Outcome of a test.

Leaf

Final prediction/decision.

16. Decision-tree traversal

To classify one case:

start at root
evaluate condition
follow matching branch
repeat
stop at leaf

So using a decision tree is itself a traversal algorithm.

17. Example

Tree:


text
Marks >= 40?
├── No  → Fail
└── Yes
     Attendance >= 75?
     ├── No  → Conditional
     └── Yes → Pass

Student:


text
Marks = 70
Attendance = 80

Trace:


text
70 >= 40 → Yes
80 >= 75 → Yes

Prediction:


text
Pass

18. Decision tree and nested selection

A decision tree is essentially a visual representation of nested if/else logic.

Tree:


text
x > 10?
├── Yes → y > 5?
│         ├── Yes → A
│         └── No  → B
└── No  → C

Equivalent idea:


text
if x > 10:
    if y > 5:
        A
    else:
        B
else:
    C

19. Features

In prediction problems, a feature is an input attribute used to make a prediction.

Examples:


text
age
income
marks
attendance
number_of_clicks

A decision-tree node usually tests one feature.

20. Target / outcome

The target is what we want to predict.

Examples:

Numerical


text
house price
temperature
sales

Categorical


text
spam / not spam
pass / fail
fraud / genuine

21. Numerical prediction

Numerical prediction means predicting a quantitative value.

Examples:

house price = ₹50 lakh
temperature = 32.4°C
demand = 1,250 units
score = 82.5

The output lies on a numerical scale.

22. Classification

Classification means assigning an observation to a category/class.

Examples:


text
spam / not spam
cat / dog
pass / fail
low / medium / high risk

Output is a label rather than an arbitrary continuous number.

23. Numerical prediction vs classification

Suppose input is student data.

Numerical prediction

Predict:

\text{final mark}=74.5

Classification

Predict:


text
Pass

or:


text
Fail

These are different problem types.

24. Binary classification

Two possible categories:


text
Yes / No
Fraud / Legitimate
Positive / Negative

This is binary classification.

25. Multi-class classification

More than two classes:


text
Low
Medium
High

or:


text
Cat
Dog
Bird

This is multi-class classification.

26. Threshold-based classification

Sometimes a numerical quantity is converted into a class using a threshold.

Example:

score\geq40

→ Pass.

Otherwise:

→ Fail.

So:

\boxed{ \text{numerical measurement} + \text{decision rule} \rightarrow \text{classification} }

27. Numerical prediction in a tree

A decision tree need not end in categories.

Example:


text
Area > 1000?
├── No
│   └── Predicted price = 30
└── Yes
    Location premium?
    ├── No  → 50
    └── Yes → 80

Leaves contain numbers.

This is a tree for numerical prediction.

28. Classification tree

If leaves contain categories:


text
Risk = Low
Risk = Medium
Risk = High

then the tree performs classification.

29. Behaviour analysis

The syllabus also lists Behaviour analysis.

At a broad CT level, this means analysing observed actions or patterns to infer something about an entity.

Examples:

shopping behaviour
web browsing behaviour
device usage
attendance patterns
transaction patterns

30. Behaviour data

Suppose a user generates:


text
pages viewed
click frequency
session duration
products purchased
time of activity

These observations may be used to characterize behaviour.

31. Behaviour analysis pipeline

Conceptually:


text
Raw actions
    ↓
Extract useful features
    ↓
Identify patterns
    ↓
Predict / classify behaviour

For example:


text
many failed logins
+
unusual location
+
rapid requests
↓
possibly suspicious behaviour

32. Behaviour analysis is not mind reading

A model observes measurable data.

It does not directly know someone's hidden intentions.

So conclusions are typically:

patterns
estimates
classifications
probabilities

not certainty about internal motives.

33. Example: customer behaviour

Observed:


text
visits per week = 8
average spend = high
recent purchases = 5

Possible classification:


text
high-engagement customer

This is classification based on behaviour features.

34. Training-data intuition

Prediction rules can be created using past examples.

Suppose historical records contain:


text
features → known outcome

Example:

Study hours	Attendance	Outcome
2	40	Fail
8	90	Pass
6	80	Pass

Patterns can be used to construct a decision rule.

35. Decision-tree split intuition

A tree tries to divide observations based on useful feature tests.

Example:


text
Attendance >= 75?

may separate many passing and failing students.

Another split:


text
Study hours >= 5?

may refine the groups further.

36. Leaves represent groups

At each decision, data are partitioned.

Example:


text
All students
    ↓
Attendance >= 75?
   /            \
No              Yes
↓                ↓
Group 1        Group 2

Then each group may be split again.

So tree construction is repeated partitioning.

37. Decision tree as recursive decomposition

A tree naturally follows recursive thinking:


text
solve prediction problem
↓
split into smaller subsets
↓
solve each subset
↓
continue until stopping condition

This links to Week 9 recursion and Week 12 top-down decomposition.

38. Prediction vs explanation

A rule may predict accurately without fully explaining the causal mechanism.

Example:


text
high usage → likely churn

may be statistically predictive but not prove:

high usage causes churn.

Keep prediction and causation conceptually distinct.

39. Rule-based classification

Not every classification system needs learned models.

You can explicitly define:


text
if age < 13:
    child
else if age < 20:
    teenager
else:
    adult

This is still classification.

40. Behaviour rules

Example:


text
if loginFailures > 5 AND newDevice:
    classify as high-risk

This is a hand-designed behavioural classifier.

Decision trees provide a structured representation of such rules.

41. Prediction error

A numerical prediction may differ from the real value.

Example:

\hat y=80

but actual:

y=75.

Prediction error:

80-75=5.

The syllabus only names numerical prediction, so detailed regression metrics are beyond the listed Week 12 scope; the important idea is that numerical predictions can be imperfect.

42. Classification error

Suppose model predicts:


text
Pass

but true label is:


text
Fail.

That is a misclassification.

Again:

\boxed{ \text{prediction}\neq\text{guarantee} }

43. Overly complex decision trees

A very deep tree can create many highly specific rules.

Conceptually:


text
if A...
    if B...
        if C...
            if D...
                ...

This can make a model difficult to understand and potentially too tailored to existing data.

The official syllabus does not list overfitting explicitly, so treat this as supporting intuition rather than a required Week 12 term.

44. Simple tree advantage

Decision trees are attractive because their logic can often be followed directly.

Example:


text
Income > 50?
↓
Yes
↓
Debt < 20?
↓
Yes
↓
Approve

You can see how the decision was produced.

45. Top-down decision-tree construction intuition

A decision tree itself is naturally built top-down:


text
root question
↓
split problem
↓
smaller subproblems
↓
more splits
↓
leaves

So two Week 12 topics connect directly.

46. Bottom-up tree reasoning

You can also reason bottom-up about existing leaves/subtrees:

understand small decision modules
combine them into larger logic

But decision-tree prediction is most naturally traversed root-to-leaf.

47. Example: numerical prediction

Suppose house data:


text
Area = 1200
Location = Premium

Tree:


text
Area >= 1000?
├── No  → 25 lakh
└── Yes
    Premium location?
    ├── Yes → 60 lakh
    └── No  → 40 lakh

Prediction:

\boxed{60\text{ lakh}}

48. Example: classification

Input:


text
Temperature = 39°C
Cough = Yes

Hypothetical rule tree:


text
Temperature > 38?
├── No  → Class A
└── Yes
    Cough?
    ├── No  → Class B
    └── Yes → Class C

Output:


text
Class C

This is only an algorithmic example, not medical guidance.

49. Classification boundary

A threshold creates a boundary.

Example:

x<50

→ Class A

x\geq50

→ Class B

Values:

49.9

and:

50

are very close numerically but fall into different categories.

That is an inherent feature of threshold-based rules.

50. Multiple-feature decisions

A tree can use several features at different levels.

Example:


text
Age >= 18?
├── No → Not eligible
└── Yes
    Income >= threshold?
    ├── No → Review
    └── Yes
        Existing debt?
        ├── High → Review
        └── Low → Eligible

The path represents a conjunction of conditions.

51. Path as logical rule

Suppose leaf is reached via:


text
Age >= 18
AND
Income >= threshold
AND
Debt = Low

Then that root-to-leaf path corresponds to one compound logical rule.

So decision trees link directly to Weeks 2–3 Boolean operators.

52. Branches must cover possibilities

If node tests:


text
x > 10?

branches should account for:

Otherwise the decision procedure may be incomplete.

This is the same exhaustiveness principle from selection statements.

53. Tree leaves should give an outcome

A decision tree traversal should eventually terminate at a leaf.

Otherwise the decision procedure is incomplete or may not terminate.

Common mistake: classifying a number means numerical prediction

Suppose output is:


text
1
2
3

Those numbers might merely be category labels.

You must ask:

Does numerical magnitude have quantitative meaning?

If not, it may still be classification.

Common mistake: numerical prediction = integer only

No.

Numerical prediction can produce:

2.7,\ 90.4,\ -5.2

or other quantitative values.

Common mistake: decision tree only supports yes/no

No.

A node can conceptually have multiple branches.

Example:


text
Colour?
├── Red
├── Blue
└── Green

Binary splits are common but not conceptually mandatory.

Common mistake: decision-tree path visits every node

No.

For one observation, you follow only one applicable branch at each decision.

Most of the tree is not visited.

Common mistake: top-down always better

A top-down design may miss useful existing components.

Bottom-up reuse may save effort.

Good design can combine both.

Common mistake: bottom-up means no planning

Bottom-up construction still requires deciding how components fit together.

It simply begins from available lower-level building blocks.

Common mistake: classification is objective truth

A classifier outputs a predicted/assigned category based on rules or learned patterns.

It may be wrong.

Especially with behavioural data:

\boxed{ \text{classification is an inference} }

Common mistake: observed behaviour proves intent

Observed:


text
rapid repeated login attempts

may correlate with suspicious activity.

But behaviour alone does not logically prove malicious intent.

Distinguish:

\text{observation} \rightarrow \text{inference}

from certainty.

62. Worked decision-tree trace

Tree:


text
             Score >= 60?
             /          \
           No            Yes
           |              |
         Fail       Attendance >= 75?
                         /      \
                       No        Yes
                       |          |
                    Review      Pass

Cases:

Score	Attendance	Result
40	90	Fail
70	60	Review
70	85	Pass

Always traverse one branch at a time.

63. Worked top-down decomposition

Problem:

Analyse student performance.

Top-level decomposition:


text
Analyse performance
├── Read records
├── Validate records
├── Compute summaries
├── Identify patterns
└── Produce report

Refine summaries:


text
Compute summaries
├── Average marks
├── Maximum marks
├── Minimum marks
└── Pass percentage

Each component can now be solved using techniques from earlier CT weeks.

64. Worked bottom-up composition

Available procedures:


text
readTable()
mean(column)
max(column)
filter(condition)
count(rows)

Combine them:


text
records = readTable()
avg = mean(records.Marks)
highPerformers = filter(Marks > avg)
n = count(highPerformers)

Small reusable pieces create the larger analysis.

65. The entire CT course converges here

Week 12 can use nearly everything from earlier weeks.

Variables

Store prediction state.

Selection

Decision-tree branches.

Procedures

Decompose problems.

Nested iteration

Analyse datasets.

Lists/tables/dictionaries

Represent data.

Graphs/trees

Represent decision structure.

Recursion

Traverse tree structures.

OOP

Package behaviour.

Concurrency

Handle larger systems.

This is why the final week feels broad.

66. Course-wide conceptual progression


text
Week 1
Basic computational state
        ↓
Week 2
Selection and filtering
        ↓
Week 3
Procedures + multiple passes
        ↓
Week 4
Nested iteration
        ↓
Week 5
Lists + sorting
        ↓
Week 6
Tables + dictionaries
        ↓
Week 7–8
Graphs + matrices
        ↓
Week 9
Backtracking + trees + DFS + recursion
        ↓
Week 10
Object-oriented organization
        ↓
Week 11
Concurrent/system interaction
        ↓
Week 12
Problem decomposition + prediction/classification

The official course description emphasizes learning programming concepts through examples that are largely executed manually, so being able to trace the state of an algorithm yourself remains the common thread across all 12 weeks.

67. Compact Week 12 terminology sheet

Top-down

\boxed{ \text{whole problem}\rightarrow\text{subproblems} }

Bottom-up

\boxed{ \text{small components}\rightarrow\text{larger solution} }

Decision tree

\boxed{ \text{tests}\rightarrow\text{branches}\rightarrow\text{leaf outcome} }

Numerical prediction

\boxed{ \text{predict quantitative value} }

Classification

\boxed{ \text{predict/assign category} }

Behaviour analysis

\boxed{ \text{observed actions}\rightarrow\text{patterns/inferences} }

68. What you should actually master

By the end of CT Week 12, you should be able to:

Explain top-down problem solving.
Decompose a large task into subproblems.
Explain bottom-up construction.
Recognize reusable components.
Compare top-down and bottom-up approaches.
Understand that real design can combine both.
Identify root, internal nodes, branches and leaves of a decision tree.
Trace an observation through a decision tree.
Translate tree paths into logical conditions.
Distinguish numerical prediction from classification.
Distinguish binary from multi-class classification.
Understand threshold-based decisions.
Explain behaviour analysis at a computational level.
Distinguish observations from inferred conclusions.
Recognize that predictions can be wrong.
Connect decision trees to selection, Boolean logic and recursion.

If those are comfortable, Computational Thinking Week 12 is under control.

Quick Recall & Flashcards

Test your active recall before proceeding to practice problems. Format:

Question :: Answer.

Week 12 Diagnostic: In Top-Down system design, what is the starting point of the architecture? :: Answer: B — Top-Down design begins with the high-level system purpose and iteratively breaks it down into smaller sub-components.
Week 12 Diagnostic: In a Decision Tree, what do internal nodes represent? :: Answer: B — Internal nodes test conditions (e.g. Age > 30); terminal leaf nodes output the predicted class or value.

Practice & Self-Check

Attempt these diagnostic questions to verify your operational understanding.

Question 1

In Top-Down system design, what is the starting point of the architecture?

MCQ

3 Unit Assessment

A. Detailed low-level utility functions

B. High-level abstract decomposition of system goals

C. The database schema

D. Unit test cases

Question 2

In a Decision Tree, what do internal nodes represent?

MCQ

3 Unit Assessment

A. Final class labels

B. Tests on an attribute or condition

C. The database table

D. Leaf predictions