23. Methodology of Problem Solving

How to Solve Problems
Problem Solving
Software University
https://softuni.bg
SoftUni Team
Technical Trainers

sli.do
#fund-common
Questions?
2

Table of Content
1. What Is a Problem?
2. Stages of Problem Solving
3. Complexity of a Problem
4. Example Problems
5. From Chaotic to Methodological Approach
3

What Is a Problem?
Current and Desired State Diff

 Definition - a doubtful or difficult matter,
requiring a solution
 Goals - anything you wish to achieve,
anywhere you want to be
 Barriers - obstacles that prevent the
achievement of goals
What Is a Problem?
5
Without goals and barriers
there is no problem

Stages
Stages of Solving a Problem

 Define the problem
 Analyse the problem
 Identify potential solutions
 Evaluate and choose the best solution
 Plan action
 Implement and review results
Solving a Problem

 What are the steps to cross the street successfully ?
Problem Street Crossing
8

 Recognizing that there is a problem, identifying the nature
of the problem, defining the problem
Problem Identification
9
Ascertain
the
objective
of the
decision
maker
Understand
the
background
of the
problem
Isolate
and
identify
the
problem
Determine
the unit of
analysis
and the
relevant
variables
State and
research
the
objective

 Observation
 Inspection
 Fact-finding
 Developing a clear picture
of the problem
Structure of the Problem
10

 Generating a range of possible courses of action and trying to
evaluate them
 Analyzing the different possible solutions and choosing the
best one
Solutions and Decisions
11

 Connect all the nine dots,
using only 4 lines
Nine Dots Problem
12

 Let's think outside the box!
 What has changed?
 Our point of view
Nine Dots Problem
13

 You are mixing cement and the recipe calls for five gallons of water
 You have a garden hose giving you all the water you need
 The problem is that you only have a four-gallon bucket and
a seven-gallon bucket and neither has graduation marks
 Find a method to measure five gallons
Five Gallons
16
4 gal 7 gal

 You have 10 stacks of 10 gold coins
 All the coins in one of these stacks are counterfeit,
all the other coins are not
 A real coin weighs 10 grams
 A counterfeit coin weighs 11 grams
 You can use an extremely
accurate digital weighing machine only once
 How do you determine which set of
10 coins is faulty?
10 Piles of 10 Coins One of Which Is Fake
17

The Missing Piece
20
 The gradient of the teal hypotenuse is different than the
gradient of the red hypotenuse

 Fill the 4-gallon bucket
 Empty the 4-gallon bucket into the 7-gallon bucket
 Pour the 3 gallons from the 4-gallon bucket
into the 7-gallon bucket
 Empty the 7-gallon bucket
 Pour the 1 gallon from the 4-gallon bucket into the 7-gallon bucket
 Empty the 4-gallon bucket into the 7-gallon bucket
 We have solved the problem
Five Gallons
21
0 gal
0 gal
4 gal 4 gal
1 gal
7 gal1 gal
5 gal

 We take one coin from pile #1, two coins from pile #2, three coins
from pile #3 and so on until we have 10 coins from pile #10
 This gives us 55 coins which if they were all pure would give us 550g
10 Piles of 10 Coins One of Which Is Fake (1)
22

10 Piles of 10 Coins One of Which Is Fake (2)
23
 However, some of them will be fake
 Let's say we place them all on the scale, for our one and only
weighing, and it reads 553g
 The only possible way this could have happened is if we placed
3 counterfeit coins on the balance, and that means that
pile #3 is counterfeit

Solving
From Chaotic to Methodological Approach

Read and Analyze the Problems
25
 Consider you are at a computer programming exam or contest
 You have 5 problems to solve in 6 hours
 First read carefully all problems and try to estimate how
complex each of them is
 Read the requirements, don't invent them!
 Start solving the easiest / fastest to solve problem first!
 Leave the most complex / slow to solve problem last!
 Approach the next problem when the previous is well tested

Use a Sheet of Paper and a Pen
26
 Never start solving a problem without a sheet of paper + a pen
 You need to sketch your ideas
 Paper and pen is the best visualization tool
 Allows your brain to think efficiently
 Paper works faster than keyboard / screen
 Other visualization tools could also work well

Prefer Squared Paper
27
 Squared paper works best for
algorithmic problems
 Easy to draw a table
 Easy to draw a coordinate
system with objects at it
 Easy to calculate distances
 Easy to sketch a problem and
solution idea

Paper and Pen
28
 Consider a "Cards Shuffle" problem
 We can sketch it to start thinking
 Some ideas immediately come, e.g.
 Split the deck into two parts and swap them multiple times
 Swap 2 random cards a random number of times
 Swap each card with a random card

Invent Ideas
Think-up, Invent Ideas and Check Them

Think Up, Invent and Try Ideas
30
 First take an example of the problem
 Sketch it on the sheet of paper
 Next try to invent some idea that works for your example
 Check if your idea will work for other examples
 Try to find a case that breaks your idea
 Try challenging examples and unusual cases
 If you find your idea incorrect, try to fix it
 Or just invent a new idea

31
 Idea #1: random number of times split the deck into left and
right part and swap them
 How to represent the cards?
 How to choose a random split point?
 How to perform the exchange?
 Idea #2: swap each card with a random card
 How many times to repeat this?
 Is this fast enough?

32
 Idea #3: swap 2 random cards a random number of times
 How to choose two random cards?
 Idea #4: choose a random card and insert it in front of the deck
 How to choose random card?
 Idea #5: do you have another idea?

Divide and Conquer
Decompose Problems into Manageable Pieces

Decompose the Problem
34
 Work decomposition is natural in engineering
 It happens every day in the industry
 Projects are decomposed into subprojects
 Complex problems could be decomposed into several smaller
sub-problems
 Technique known as "Divide and Conquer"
 Small problems could easily be solved
 Smaller sub-problems could be further decomposed as well

Divide and Conquer – Example
35
 Let's try idea #1:
 Split the deck into left and right part and swap them
(many times)
 Divide and conquer
 Sub-problem #1 (single exchange) – split the deck into two
random parts and exchange them
 Sub-problem #2 – choosing a random split point
 Sub-problem #3 – combining single exchanges
 How many times to perform "single exchange"?

Sub-Problem #1 (Single Exchange)
36
 Split the deck into two parts at random split point
 And exchange these 2 parts
 We visualize this by paper and pen:

37
 Choosing a random split point
 Need to understand the concept of pseudo-random numbers
and how to use it
 In Internet lots of examples are available, some of them incorrect
 The class System.Random can do the job
 Important detail is that the Random class should be
instantiated only once
 Not at each random number generation

38
 Combining a sequence of single exchanges to solve
the initial problem
 How many times to perform single exchanges to reliably
randomize the deck?
 N times (where N is the number of the cards) seems enough
 We have an algorithm:
 N times split at random position and exchange the left and right
parts of the deck

Check-Up Your Ideas
Don't Go Ahead Before Checking Your Ideas

Check-Up Your Ideas
40
 Check-up your ideas with examples
 It is better to find a problem before the idea is implemented
 When the code is written, changing your ideas radically costs a
lot of time and effort
 Carefully select examples for check-up
 Examples should be simple enough to be checked
by hand in a minute
 Examples should be complex enough to cover the most general
case, not just an isolated case

Check-Up Your Ideas – Example
41
 Let's check the idea:
 After 3 random splits and swaps we obtain the start position
 Seems like a serious problem!

Invent New Idea If Needed
42
 What to do when you find your idea is not working in all cases?
 Try to fix your idea
 Sometimes a small change could fix the problem
 Invent new idea and carefully check it
 Iterate
 Usually your first idea is not the best
 Invent ideas, check them, try various cases, find problems,
fix them, invent better ideas, etc.

Invent New Ideas – Example
43
 Invent a few new ideas:
 New idea #1 – multiple times select 2 random cards and
exchange them
 New idea #2 – multiple times select a random card and
exchange it with the first card
 New idea #3 – multiple times select a random card and move it
to an external list
 Let's check the new idea #2
 Is it correct?

Check-Up the New Idea – Example
44

Implementation
Coding and Testing Step-By-Step

Start Coding: Checklist
46
 Never start coding before you find a correct idea that will meet
the requirements
 What shall you write before you have a correct idea?
 Checklist to follow before start of coding:
 Ensure you understand the requirements well
 Ensure you have come up a good idea
 Ensure your idea is correct
 Ensure you know what data structures to use
 Ensure the performance will be sufficient

Implement Your Algorithm Step-By-Step
47
 "Step-by-step" approach is always better than
"build all, then test"
 Implement a piece of your program and test it
 Then implement another piece of the program and test it
 Finally put together all pieces and test it
 Small increments (steps) reveal errors early
 "Big bang" integration takes more time

Testing the Code
Thoroughly Test Your Solution

Thoroughly Test Your Solution
49
 Always test thoroughly your solution
 Invest in testing!
 One 90-100% solved problem could be better than 2 or 3
partially solved
 Testing an existing problem takes less time than solving another
problem from scratch

How to Test?
50
 Testing could not certify absence of defects
 It just reduces the defects’ rates
 Well tested solutions are more likely to be correct
 Start testing with a good representative of the general case
 Not a small isolated case, but a typical one
 Large enough test case, but small enough to be easily checkable

Read the Problem Statement
51
 Read carefully the problem statement
 Does your solution print exactly what is expected?
 Does your output follow the requested format?
 Did you remove your debug printouts?
 Be sure to solve the requested problem, not the problem
you think is requested!
 Example: "Write a program to print the number of
permutations of n elements" means to print a single number,
not a set of permutations!

 …
 …
 …
Summary
52
 Problem solving needs methodology:
 Understanding and analyzing problems
 Using a sheet of paper and a pen for sketching
 Thinking up, inventing and trying ideas
 Decomposing problems into sub-problems
 Selecting appropriate data structures
 Thinking about the efficiency and performance
 Implementing step-by-step
 Testing the nominal case, border cases and efficiency

 https://softuni.bg/courses/programming-fundamentals

SoftUni Organizational Partners

 Software University – High-Quality Education and
Employment Opportunities
 softuni.bg
 Software University Foundation
 http://softuni.foundation/
 Software University @ Facebook
 facebook.com/SoftwareUniversity
 Software University Forums
 forum.softuni.bg
Trainings @ Software University (SoftUni)

 This course (slides, examples, demos, videos, homework, etc.)
is licensed under the "Creative Commons Attribution-NonCom
mercial-ShareAlike 4.0 International" license
License
57

23. Methodology of Problem Solving

More Related Content

What's hot (20)

Similar to 23. Methodology of Problem Solving (20)

More from Intro C# Book (20)

Recently uploaded (20)

23. Methodology of Problem Solving