How To Think: Part 1
by pythag011, Dec 14, 2011, 10:10 PM
A semi-concrete post? WHAT IS THIS MADNESS
This post is going to be a general discussion of certain ways to approach problems. Next part will be a specific example. Maybe there will be more posts in the future.
The most important thing to remember is NEVER FOLLOW RULES BECAUSE I TOLD YOU TO. I see a lot of people who try small cases for the sake of trying small cases, don't learn anything from the small cases, and are just like "ok next method." If you don't know why looking at small cases is likely to be helpful for the problem, try to figure out why. If you just look at small cases for the sake of looking at small cases, you will not improve veyr much at using the tool of small cases.
Onto the general discussion.
(Note: The most important general statements will be labeled GSSP and bolded.)
So, starting the problem.
GSSP 1: Don't start the problem by trying to solve the problem, start the problem by understanding the problem.
How not to start solving a problem: Hmm, the problem has an integer n in the problem, let's try induction! (Wait, it's a diophantine equation...)
Don't blindly try random methods on problems. This sounds obvious, but for some reason everyone does it.
This is a large part of why you don't want to do only easy problems: if you do that, you get used to instantly seeing the approach that solves the problem, and you don't want to have to rely on "seeing" the correct approach instantly.
But then where does the result you want come in? Hmm...
GSSP 2: What the problem tells you to prove will tell you which sorts of understanding of the problem is most important
If a problem tells you to prove some geometry ratios are equal, then you should think "Hmm, maybe I should look for similar triangles... so I should understand the problems through similar triangles."
--Understanding the Problem--
GSSP 3: Understanding a problem is usually done either by looking for patterns or by re-evaluating what is important.
In general, my problem solving usually goes like:
1. Evaluate the problem: What sort of results will be important?
2. Look for patterns.
3. Find some patterns, make some conjectures based on patterns.
4. Try some methods.
5a. You're done.
5b. The method failed. Ask yourself why the method failed. Figure out what about the problem made the method fail; this gives you insight, and lets you create a better answer for step 1. Go back to step 1.
This is something that is largely by habit, you shouldn't follow it. Find your own method.
Let's go more in-depth on these two ideas...
--Looking for Patterns--
GSSP 4: Small/specific cases and the patterns you find from looking at them are amazingly useful.
Sometimes I ask people about small cases and they reply with something along the lines of "small cases are easy." But anyone who could actually do small/specific cases properly would get a perfect score on the USAMO/IMO in < 5 minutes. People don't realize how incredibly powerful looking at small/specific cases is when done right, and how useless it is when done wrong.
So I'm going to get asked, well, how do you look at small cases?
This is a question that is very hard to answer, but I'll give two general guidelines that I find useful.
GSSP 5: The first step to using small/specific cases is to be convinced and aware of their power, and convince yourself that you have no clue how to use small cases.
(Sort of a parallel to "the first step of learning is convincing oneself of one's ignorance.")
GSSP 6: The small cases you look at will change with what you find important. Your methods may make clear that certain examples are very interesting, and you should look at those. Small cases are not something you do once on a problem and then stop doing.
There are other methods of looking for patterns. In particular:
GSSP 7: Look at similar problems.
The similar problems you can remember from the past or create them on the spot. I would write more, but I feel like I should just link you to http://www.dpmms.cam.ac.uk/~wtg10/cubic.html, written by Timothy Gowers instead.
--What is important?--
I find this question useful to ask every time I get a new piece of information. I see a pattern? What aspects of the problem seem related to the pattern, and thus more important?
A sense of "what is important" is essentially intuition. It is something that is developed over time, though the time taken is much shorter if you do exclusively Russian problems.
Patterns are very useful for this, but the most important use of this....
GSSP 8: Every time you try a method and it fails, don't be satisfied with just moving on to another method. Understand the roadblocks in the problem that made the method fail. Once you figure out what roadblocks those are, then you can figure out what methods/results are likely to get past that roadblock, and you can try to focus on those. Ask yourself "Why is this problem hard?"
A lot of mathematics is motivated by this heuristic. An elementary example will be given in the next post in this series, but here, I'm going to use an example from calculus/analysis:
The Riemann integral is what is typically used in calculus. Unfortunately, it suffers from some rather annoying insufficiencies; For example, the integral of a function that is the limit of a sequence of functions may not equal the limit of the integrals of the functions, and it is hard to find conditions for which the two are the same. Once you are aware that this is a problem, it becomes natural to search for a better definition of integral, which leads to the Lebesgue integral, which satisfies the http://en.wikipedia.org/wiki/Dominated_convergence_theorem.
This post is going to be a general discussion of certain ways to approach problems. Next part will be a specific example. Maybe there will be more posts in the future.
The most important thing to remember is NEVER FOLLOW RULES BECAUSE I TOLD YOU TO. I see a lot of people who try small cases for the sake of trying small cases, don't learn anything from the small cases, and are just like "ok next method." If you don't know why looking at small cases is likely to be helpful for the problem, try to figure out why. If you just look at small cases for the sake of looking at small cases, you will not improve veyr much at using the tool of small cases.
Onto the general discussion.
(Note: The most important general statements will be labeled GSSP and bolded.)
So, starting the problem.
GSSP 1: Don't start the problem by trying to solve the problem, start the problem by understanding the problem.
How not to start solving a problem: Hmm, the problem has an integer n in the problem, let's try induction! (Wait, it's a diophantine equation...)
Don't blindly try random methods on problems. This sounds obvious, but for some reason everyone does it.
This is a large part of why you don't want to do only easy problems: if you do that, you get used to instantly seeing the approach that solves the problem, and you don't want to have to rely on "seeing" the correct approach instantly.
But then where does the result you want come in? Hmm...
GSSP 2: What the problem tells you to prove will tell you which sorts of understanding of the problem is most important
If a problem tells you to prove some geometry ratios are equal, then you should think "Hmm, maybe I should look for similar triangles... so I should understand the problems through similar triangles."
--Understanding the Problem--
GSSP 3: Understanding a problem is usually done either by looking for patterns or by re-evaluating what is important.
In general, my problem solving usually goes like:
1. Evaluate the problem: What sort of results will be important?
2. Look for patterns.
3. Find some patterns, make some conjectures based on patterns.
4. Try some methods.
5a. You're done.
5b. The method failed. Ask yourself why the method failed. Figure out what about the problem made the method fail; this gives you insight, and lets you create a better answer for step 1. Go back to step 1.
This is something that is largely by habit, you shouldn't follow it. Find your own method.
Let's go more in-depth on these two ideas...
--Looking for Patterns--
GSSP 4: Small/specific cases and the patterns you find from looking at them are amazingly useful.
Sometimes I ask people about small cases and they reply with something along the lines of "small cases are easy." But anyone who could actually do small/specific cases properly would get a perfect score on the USAMO/IMO in < 5 minutes. People don't realize how incredibly powerful looking at small/specific cases is when done right, and how useless it is when done wrong.
So I'm going to get asked, well, how do you look at small cases?
This is a question that is very hard to answer, but I'll give two general guidelines that I find useful.
GSSP 5: The first step to using small/specific cases is to be convinced and aware of their power, and convince yourself that you have no clue how to use small cases.
(Sort of a parallel to "the first step of learning is convincing oneself of one's ignorance.")
GSSP 6: The small cases you look at will change with what you find important. Your methods may make clear that certain examples are very interesting, and you should look at those. Small cases are not something you do once on a problem and then stop doing.
There are other methods of looking for patterns. In particular:
GSSP 7: Look at similar problems.
The similar problems you can remember from the past or create them on the spot. I would write more, but I feel like I should just link you to http://www.dpmms.cam.ac.uk/~wtg10/cubic.html, written by Timothy Gowers instead.
--What is important?--
I find this question useful to ask every time I get a new piece of information. I see a pattern? What aspects of the problem seem related to the pattern, and thus more important?
A sense of "what is important" is essentially intuition. It is something that is developed over time, though the time taken is much shorter if you do exclusively Russian problems.
Patterns are very useful for this, but the most important use of this....
GSSP 8: Every time you try a method and it fails, don't be satisfied with just moving on to another method. Understand the roadblocks in the problem that made the method fail. Once you figure out what roadblocks those are, then you can figure out what methods/results are likely to get past that roadblock, and you can try to focus on those. Ask yourself "Why is this problem hard?"
A lot of mathematics is motivated by this heuristic. An elementary example will be given in the next post in this series, but here, I'm going to use an example from calculus/analysis:
The Riemann integral is what is typically used in calculus. Unfortunately, it suffers from some rather annoying insufficiencies; For example, the integral of a function that is the limit of a sequence of functions may not equal the limit of the integrals of the functions, and it is hard to find conditions for which the two are the same. Once you are aware that this is a problem, it becomes natural to search for a better definition of integral, which leads to the Lebesgue integral, which satisfies the http://en.wikipedia.org/wiki/Dominated_convergence_theorem.
This post has been edited 1 time. Last edited by pythag011, Dec 14, 2011, 10:13 PM