38
How to Solve It (with a tip of the hat to G. Polya) • Practical Computer Programming • CSEM05 • University of Sunderland

How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Embed Size (px)

Citation preview

Page 1: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

How to Solve It(with a tip of the hat to G. Polya)

• Practical Computer Programming• CSEM05• University of Sunderland

Page 2: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Resources

• G. Polya (1957) How to Solve It, 2nd edition, Doubleday Anchor Books

Page 3: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Introduction

• For most of us, computer programming is done for a reason—to solve a problem.

• The language defines various kinds of operations, mostly mathematical, that we can use to do that.

• But first, we need to understand how problems are solved.

• Then we can talk about how to use the features of Java to design a solution.

Page 4: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Outline

• How to solve it.• How to use Java to solve it.

Page 5: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

How to Solve it

• Polya was concerned with the heuristics of finding a solution to a mathematical problem. These consists of four stages:1. Understanding the problem2. Devising a plan3. Carrying out the plan4. Looking back

Page 6: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Understanding the Problem

• First you have to understand the problem.– What are you computing—the unknown?– What are the data?– What are the constraints or conditions?– Draw a figure.– Choose a notation.– Break the problem apart.– Do you understand the parts of the problem?

Page 7: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Devising a Plan

• Next, you have to devise a plan.– What is the connection between the data and the unknown?– Have you seen it before?– Do you know a related problem?– Look at the unknown and try to think of a familiar problem

with the same unknown.– Look for related and previously solved problems.– Can you restate the problem?– Are you using all the data?– Have you taken into account all the ideas?

• Use this to define a plan.

Page 8: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Nota Bene

• A computer program is a plan.• Your brain is good at planning.• So the problem is translating your plan into

programming notation.

Page 9: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Carrying out the Plan

• Write a program to perform the plan.• Check each step.• Design tests that a correctly programmed plan

will pass.• Debug the program until each test is passed.• Run the program.

Page 10: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Looking Back

• Examine your plan and the program you wrote.

• Is there a way of checking your results?• Could you write the program differently?• Could you use a different plan?• Can you use the results or the method for

some other problem?

Page 11: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Ideas

• Analogy• Scaffolding (auxiliary

elements)• Corollaries• Decomposing and

Recombining• Determination• Guessing• Figures

• Generalization• Induction• Inventor’s Paradox• Look at the Goal• Notation• Indirect Proof• Separate the Parts of

the Condition• Signs of Progress

Page 12: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Analogy

• A sort of similarity. Analogous programs seem to have the same design or design approach.

• We use analogy a lot, so exploit it.• The basic concept of object-oriented

programming is analogy.• Look for simpler analogous programs.• Try to solve a simpler analogous problem.• Look for patterns.

Page 13: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Scaffolding (auxiliary elements)

• Elements you add to your analysis to aid in solving the main problem.

• Intermediate steps on the road to your solution.

• Elements you add to a problem to convert it to a problem you’ve solved before.

• Elements you add to a program to hold data for later.

Page 14: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Corollaries

• Programs you can write easily using the program you’ve just written.

• Part of looking back.

Page 15: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Decomposing and Recombining

• Breaking something down to its elements and creating new things from the elements.

• Suppose you’ve written two methods to solve a part of the problem. Consider breaking them down to their steps or blocks and reorganizing them differently.

• Use the same approach to classes.

Page 16: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Determination

• Also hope or success.• True grit.• Determination and emotions play a role in

writing a program, especially a hard problem.• “You can undertake without hope and

persevere without success.”• If the problem is too hard, try something

simpler but related first.

Page 17: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Guessing

• Guesses are the grist for your mill. They help you extend your plan.

• But, test your guesses.• Be willing to be wrong.

Page 18: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Figures

• Not everyone thinks the same way. Some people use words, some use pictures, and some even use touch. Translate the problem into a visual format. Rewrite it. Read it out loud. Read it out loud to a friend. Explain the problem to a friend. Fill a home with the parts of the problem. Think of it as a hunting trip into the wilderness.

• Do what you need to do to gain insight.

Page 19: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Generalization

• It’s sometimes much easier to solve a more general problem than the specific problem you’re working on.

• Look for ways to generalize the problem.

Page 20: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Induction

• A mathematical proof approach.– Suppose you know how to solve the problem for an

input value of 0.– Next suppose you can define the solution for an

input value of N+1 if you know the solutions for 0 up to N.

– Then you can solve the problem for an input values.• Two programming techniques support induction:

1. Looping2. Recursion

Page 21: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Looping

• for(int i=0; i<N; i++){action for the ith case}• for(ClassType c:(container or array of

ClassType)){action for object c}• do{actions;}while(something is true);• while(something is true){actions;}• break; // exits out of a loop• continue; // completes an action in a loop

Page 22: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Recursion

• A method can call itself directly or indirectly– Type foo(arguments){calls foo(other arguments);}

• To make recursion work for you in Java, you have to show that the recursion eventually returns without calling foo().

• You can have foo() call bar(), which calls baz(), which eventually calls foo(). This is still recursion.

Page 23: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Inventor’s Paradox

• “The more ambitious plan may have more chances of success.”

• The more general problem may be easier to solve.

Page 24: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Look at the Goal

• Respice finem.• Remember your aim.• Work backwards from the goal.• Look at other ways of gaining the goal. Can

you adapt them to your program?• Can you introduce auxiliary elements that

convert your problem into a solved problem?

Page 25: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Notation

• A good notation is like a good figure—it suggests solutions.

Page 26: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Indirect Proof

• Suppose you have a (finite) number of possible endstates that you can generate.

• Computers are powerful—generate them all and throw out the invalid ones.

Page 27: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Separate the Parts of the Condition

• Break the problem down into its pieces. • Solve each individual piece. (Sometimes you

can solve them in parallel.)• Put the solution together from the individual

solutions.

Page 28: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Signs of Progress

• Look for signs of progress.• A partial solution is a good sign.• A solution for some specific input cases is a

good sign.• Convert the signs of progress into automated

tests with JUnit. Make sure you don’t lose ground.

Page 29: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

How to use Java to Solve it

• A program implements a plan. The important parts of a Java program for planning are:– Declarations– Expressions and operators– Syntactical statements– Class definitions– Array definitions– Method calls– Containers and iterators

Page 30: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Why Java?

• Java can run on almost any hardware platform. You can write the program on a Windows 7 machine and run it on a Mac or Linux machine.

• Java allows you to do things in parallel. This is a bit of an advanced topic. If you’re interested, look up ‘threads’ in Java.

• Next, the Java language:

Page 31: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Declarations

• A declaration introduces a name into the program and describes what it is.

• It can introduce a class, a primitive type, a method, or a number of other things.

• Think of it as introducing an auxiliary element.• public static void main(String[] args){…}

introduces the very first things you’re dealing with in the program—the callable main method.

Page 32: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Expressions and operators

• Expressions and operators allow you to manipulate your auxiliary elements.

• Some involve arithmetic, some logic, and some more tangible things like strings.

• You can usually do something several different ways.

Page 33: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Syntactical statements

• By default, Java executes statements in order.• You can also use the following ideas:– if then else, for decisions– switch for a table of alternatives– various loops (earlier)– method calls on classes or objects– return to exit a method– throw to exit a method in a non-standard way. (This

involves try, catch, finally blocks.)– assert to exit a method in a non-standard way.

Page 34: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Class definitions

• Classes have two functions:– To package data in a standard way (abstract data types)– To define operations on an object or the class

• Classes contain– Methods, and– Attributes.

• Classes can implement generalization by inheritance and the extends keyword. This saves coding.

• Classes can implement polymorphism by interfaces (and the implements keyword) and by inheritance from abstract classes. This hides implementation from users.

Page 35: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Array definitions

• An array is an ordered list with a fixed length.• The contents of an array are variables of a

primitive or reference type.• Arrays can be used as tables or as something

to be looped through.

Page 36: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Method calls

• Methods allow you to structure your sequence of actions intelligently. Think of them as small programs your program can call.

Page 37: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Containers and Iterators

• Java provides container classes for various purposes. They have Iterators, but the for-in loop conveniently hides that machinery.

• Container classes include:– Lists– Maps– Sets

• Java allows you to declare that a container contains objects of a given Type by declaring it CC<Type>, where CC is a container class.

• To store primitive types in a container, the Type should be a ‘wrapper class’: Integer, Double, Boolean, and Character are the ones you will usually use.

Page 38: How to Solve It (with a tip of the hat to G. Polya) Practical Computer Programming CSEM05 University of Sunderland

Conclusions

• Understanding the problem—don’t start writing your program until you have an idea of what the program should do.

• Devising a plan—come up with a way of getting to the goal from the inputs. This need not be completely defined until later.

• Carrying out the plan—program it, using JUnit to check that the signs of progress don’t disappear.

• Looking back—think about what you wrote.