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

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

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

3. 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.

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

5. How to Solve it • Polya was concerned with the heuristics of finding a solution to a mathematical problem. These consists of four stages: • Understanding the problem • Devising a plan • Carrying out the plan • Looking back

6. 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?

7. 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.

8. Nota Bene • A computer program is a plan. • Your brain is good at planning. • So the problem is translating your plan into programming notation.

9. 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.

10. 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?

11. 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

12. 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.

13. 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.

14. Corollaries • Programs you can write easily using the program you’ve just written. • Part of looking back.

15. 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.

16. 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.

17. Guessing • Guesses are the grist for your mill. They help you extend your plan. • But, test your guesses. • Be willing to be wrong.

18. 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.

19. 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.

20. 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: • Looping • Recursion

21. Looping • for(inti=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

22. 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.

23. Inventor’s Paradox • “The more ambitious plan may have more chances of success.” • The more general problem may be easier to solve.

24. 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?

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

26. 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.

27. 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.

28. 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.

29. 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

30. 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:

31. 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.

32. 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.

33. 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.

34. 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.

35. 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.

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

37. 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.

38. 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.