6 votes

How do you model complicated or tricky problems to solve them? What benefit do you get from using that model?

Everyone has their own way of visualizing a problem they're working on, and every strategy has some reason for being used. Some people prefer text (e.g. pseudocode) while others prefer diagrams, for example. What do you use to make problems easier to approach, conceptualize, and solve? Why that particular strategy rather than some other one? What kind of practical implementations of your strategy exemplifies the benefits of your strategy for modeling the problem?

5 comments

  1. panic
    Link
    It depends on the problem! Drawings work great for some things (geometrical problems, graph problems), but other things (step-by-step processes) are easier to work with as text.

    It depends on the problem! Drawings work great for some things (geometrical problems, graph problems), but other things (step-by-step processes) are easier to work with as text.

    3 votes
  2. [4]
    Social
    Link
    ~~ One that I like is to start at the finish and work backwards.~~ Edit: Apparently I missed the question.

    ~~ One that I like is to start at the finish and work backwards.~~
    Edit: Apparently I missed the question.

    1. [3]
      Emerald_Knight
      Link Parent
      No worries. It sounds like an interesting approach nonetheless. Perhaps you could expand on the idea more? It could be a valuable problem-solving process to take note of :)

      No worries. It sounds like an interesting approach nonetheless. Perhaps you could expand on the idea more? It could be a valuable problem-solving process to take note of :)

      1. [2]
        Social
        Link Parent
        Sure. Although I've only tried using this method where the flow of the program has been straight forward and only had one line. When we design things we may design things at different levels of...

        Sure. Although I've only tried using this method where the flow of the program has been straight forward and only had one line.

        When we design things we may design things at different levels of detail and that applies to this model as well. So you can make one high level version of this and at least one more low level.

        We begin with our goal / final box in a flowchart. What do we do right before we get there? What do we do right before that? After asking that question enough times you see that you're at the starting point of the process / method / flow chart.

        What's usefull about this is that you begin with the finished process. It's sometimes easier figuring out how to go backwards because you know that you'll end up in the right place rather than not knowing which steps you need to take to get there. It's really tough trying to explain this, but it's as if you start at the top of the mountain and find the easiest path down. There are fewer possibilities at the top so it's easier to find something viable. Instead of starting at the bottom and running into dead ends.

        I hope you can benefit from this approach.

        1 vote
        1. Emerald_Knight
          Link Parent
          That sounds perfectly logical, actually. Generally I just start with an abstract overview and, in stages, flesh it out in greater detail because I already know the general shape of the problem,...

          That sounds perfectly logical, actually. Generally I just start with an abstract overview and, in stages, flesh it out in greater detail because I already know the general shape of the problem, but there are definitely cases where it makes sense to work backwards because you only know what you expect the end result to be and don't really have a fully formed idea of how to get there (or maybe you're just missing some critical detail that you can't quite work out from the forward approach).

          Definitely a good thing to keep in mind!