PDA

View Full Version : How do you think / solve problems?



jseah
2013-05-08, 10:28 PM
A friend asked and I decided to try some introspection. But essentially, this is an attempt at describing how I solve problems. Easiest examples are the usual math ones but less structured open-ended problems like planning a storyline are also considered.

How do you solve problems?

For very simple problems, I can see them as one step. Eg. the usual A has 5 more pins than B, 20 total pins, how many does A have, sort of problem.
I can see all the steps, I see what each step will do to the information in the problem and I see that at the end of the steps, the form of the information is the same as the answer. But I do not know the answer until I actually perform the calculations, I just know that these steps will get me the answer.
Describing this part is very hard. I do not really know how I 'just know' these set of steps will change the information in some way and how I can recognize when the changed information is the same as my answer.

For more complicated problems, the sort where the solution doesn't pop into mind instantly, I solve them by a series of smaller steps like the one above. I start from the information given and try doing things to them. Meanwhile, I also start from what I know the answer is like and work backwards (if it has a defined answer). If the two meet, I have my solution, I just reverse all the steps going back from the answer.
Eg. Car A is travelling at 90km/h and passes stationary car B. Car B immediately begins to accelerate at 10km/h until it reaches 120km/h, how long does it take for car B to overtake car A? I guess that it will happen after B reaches its speed limit so I know what the graph of their speeds will look like. I know that B will pass A at some point so I also know what their distance graphs look like. I can work backwards from there and reach say, "I need to know how far they have gone when B reaches its maximum speed".

For long problems where I cannot remember everything at the same time, I create checkpoints. After a number of steps that feels "right", I forget all the steps needed to get to the checkpoint and just remember the checkpoint as a single large step. I can always work it out again.
Occasionally, I can just skip the whole exploring by steps part and just skip ahead to the checkpoints trusting that I can get to the checkpoint because it is similar to something I have done before.
Eg. Create a general solution for finding the point furthest along a given line and start point that is outside multiple overlapping circles. I might create a checkpoint at "get a point just outside a circle along this line". I know I can do it, so I don't bother to remember how.

For more difficult problems, I sometimes step back when I understand it to say "ok, how many different ways can I look at this problem"?
Eg. A character gets 2 extra attacks 50% of the time every time it makes 1 attack. How many attacks does this character get on average? You can consider it from the point of view of "average number of extra attacks per attack made" (which is 1); you can also look at it like a graph:
You start at 1,1. Every step along the X-axis is one attack/coin flip, the y-axis is the number of attacks left. Throw a head, you go up one, otherwise go down one. If you hit zero along the y, you stop. This is a random walk.
These are two ways of looking at the problem and it changes what the problem looks like even though I know the problem is same. Sometimes when I do this, a problem can vastly simplify or at least look very simple so I try every way of looking at a difficult problem first to see if I find anything that will make it easier.

Out of all this, I also have a number of other less used ways.
Occasionally, I can just look at a problem and instantly know "this is solvable"; although I can be wrong and never work out the solution, it is alot better than chance. Even more rarely, this can be coupled with an instant solution (which can also be wrong), although this is less likely the more complicated a problem is, but I have gotten "instant solutions" for problems that required checkpoints to solve normally. "instant solutions" can sometimes even suggest different ways of looking at a problem.

What I think "instant solutions" are is that they are actually very much like the result of what I call a Push. Apart from systematically solving the problem like above, which is tiring, I can look at the whole problem and just Push and sometimes, I get a solution falling out.
Pushing is not tiring at all (its about as close to free as thinking gets) and I do this when I'm too lazy or tired to spend effort on the problem. While I do sometimes get solutions randomly without even thinking, I get them alot more and faster if I Push a problem.

I can use a Push on anything at all, even problems that are normally too complicated, and sometimes get an answer. Complicated problems take longer and are more likely to never get one though. Most commonly, I use a Push on problems that are open-ended and more than one answer is possible with a rank of how good an answer they are. Push solutions are usually more weird than the systematic method.
eg. Plan a storyline for a certain plot or choreograph a specific scene. There are many ways to do this and some of them are better than others, you can always look for a better answer.

To my best description, a Push is a process where I match concepts to each other and see if they solve my problem. Push is very fast at doing this, I can feel the concepts being tried (sort of) but they go by faster than I can understand them. They are not really fully formed concepts I can write down or think about clearly as they're incoherent until they match up. I know they exist because I can guide what sort of solution comes out (I still get weird off-field ones), but they're hard to describe. Just trying to describe them changes them into something coherent and not the same thing.
A Push is often biased. If I got a solution once from it and rejected it to try again, I will often get the same thing again very soon. Fortunately Push is free and I've learnt to ignore repeat answers although not perfectly.
Ever since I started writing however, I've gotten better at controlling how off-field an answer I get.

Shadow of the Sun
2013-05-08, 10:50 PM
A friend asked and I decided to try some introspection. But essentially, this is an attempt at describing how I solve problems. Easiest examples are the usual math ones but less structured open-ended problems like planning a storyline are also considered.

How do you solve problems?

For very simple problems, I can see them as one step. Eg. the usual A has 5 more pins than B, 20 total pins, how many does A have, sort of problem.
I can see all the steps, I see what each step will do to the information in the problem and I see that at the end of the steps, the form of the information is the same as the answer. But I do not know the answer until I actually perform the calculations, I just know that these steps will get me the answer.
Describing this part is very hard. I do not really know how I 'just know' these set of steps will change the information in some way and how I can recognize when the changed information is the same as my answer.

For more complicated problems, the sort where the solution doesn't pop into mind instantly, I solve them by a series of smaller steps like the one above. I start from the information given and try doing things to them. Meanwhile, I also start from what I know the answer is like and work backwards (if it has a defined answer). If the two meet, I have my solution, I just reverse all the steps going back from the answer.
Eg. Car A is travelling at 90km/h and passes stationary car B. Car B immediately begins to accelerate at 10km/h until it reaches 120km/h, how long does it take for car B to overtake car A? I guess that it will happen after B reaches its speed limit so I know what the graph of their speeds will look like. I know that B will pass A at some point so I also know what their distance graphs look like. I can work backwards from there and reach say, "I need to know how far they have gone when B reaches its maximum speed".

For long problems where I cannot remember everything at the same time, I create checkpoints. After a number of steps that feels "right", I forget all the steps needed to get to the checkpoint and just remember the checkpoint as a single large step. I can always work it out again.
Occasionally, I can just skip the whole exploring by steps part and just skip ahead to the checkpoints trusting that I can get to the checkpoint because it is similar to something I have done before.
Eg. Create a general solution for finding the point furthest along a given line and start point that is outside multiple overlapping circles. I might create a checkpoint at "get a point just outside a circle along this line". I know I can do it, so I don't bother to remember how.

For more difficult problems, I sometimes step back when I understand it to say "ok, how many different ways can I look at this problem"?
Eg. A character gets 2 extra attacks 50% of the time every time it makes 1 attack. How many attacks does this character get on average? You can consider it from the point of view of "average number of extra attacks per attack made" (which is 1); you can also look at it like a graph:
You start at 1,1. Every step along the X-axis is one attack/coin flip, the y-axis is the number of attacks left. Throw a head, you go up one, otherwise go down one. If you hit zero along the y, you stop. This is a random walk.
These are two ways of looking at the problem and it changes what the problem looks like even though I know the problem is same. Sometimes when I do this, a problem can vastly simplify or at least look very simple so I try every way of looking at a difficult problem first to see if I find anything that will make it easier.

Out of all this, I also have a number of other less used ways.
Occasionally, I can just look at a problem and instantly know "this is solvable"; although I can be wrong and never work out the solution, it is alot better than chance. Even more rarely, this can be coupled with an instant solution (which can also be wrong), although this is less likely the more complicated a problem is, but I have gotten "instant solutions" for problems that required checkpoints to solve normally. "instant solutions" can sometimes even suggest different ways of looking at a problem.

What I think "instant solutions" are is that they are actually very much like the result of what I call a Push. Apart from systematically solving the problem like above, which is tiring, I can look at the whole problem and just Push and sometimes, I get a solution falling out.
Pushing is not tiring at all (its about as close to free as thinking gets) and I do this when I'm too lazy or tired to spend effort on the problem. While I do sometimes get solutions randomly without even thinking, I get them alot more and faster if I Push a problem.

I can use a Push on anything at all, even problems that are normally too complicated, and sometimes get an answer. Complicated problems take longer and are more likely to never get one though. Most commonly, I use a Push on problems that are open-ended and more than one answer is possible with a rank of how good an answer they are. Push solutions are usually more weird than the systematic method.
eg. Plan a storyline for a certain plot or choreograph a specific scene. There are many ways to do this and some of them are better than others, you can always look for a better answer.

To my best description, a Push is a process where I match concepts to each other and see if they solve my problem. Push is very fast at doing this, I can feel the concepts being tried (sort of) but they go by faster than I can understand them. They are not really fully formed concepts I can write down or think about clearly as they're incoherent until they match up. I know they exist because I can guide what sort of solution comes out (I still get weird off-field ones), but they're hard to describe. Just trying to describe them changes them into something coherent and not the same thing.
A Push is often biased. If I got a solution once from it and rejected it to try again, I will often get the same thing again very soon. Fortunately Push is free and I've learnt to ignore repeat answers although not perfectly.
Ever since I started writing however, I've gotten better at controlling how off-field an answer I get.

Is this really appropriate for media? Seems a more General Chat kind of thing.

Hopeless
2013-05-11, 02:42 PM
Well it largely depends on the situation.

Sometimes its because it hits you right in the face that you're left thinking... Hey what about that?

Then there's the obscure route where you're presented with a problem that will only make sense if you're familiar with whoever thought it up or actually know more than they do... sort of that thread from a few years ago where the dm wondered why the fantasy group didn't recognise the chemical composition of coca cola or something like that.

Best case I can make as an example is when I played in an online game and we find a secret door that the barbarian promptly uses revealing the floor beyond that secret door is lined with dart traps.

Looking back over the description given by the dm about the room I post asking whether we could use the furniture in the room to cover the floor thereby bypassing the traps.

Sounds simple doesn't it, but what might be obvious to me might not work the next time or the time after that and then there's the odds mere chance will solve a situation but that relies on the dm trying to run a fun game instead of a game that devolves into a tpk because they either can't adapt to the situation or their players can't cope with their planned adventure.

Hope that helps!

Traab
2013-05-11, 03:12 PM
I tend to break the problem down into base elements and look for patterns. Thats also how I memorize things like passwords and pin numbers. I try to either find a pattern with them, or associate them with something else. Lets say I have a pin number 2633. One way I can make it stick in my head is to break it up into pairs, 26, 33. Two numbers are easier to remember than 4 after all. Another way is to realize that this number spells the word code on my phone. So I remember my pin number is CODE and bam, I memorize it. (Thats not my pin number, nor the number of anyone I know of.)