Perpendicular Problem Solving
A breakdown and explanation of tree-based thought processes.
============================================================================
J.H. Reidhead III
Feb 2024
============================================================================
Consider a space in which you can visualize all elements included in the path to solving a problem. From the outside perspective, a problem begins to take shape when you begin to idealize a solution. But is this structural shape-based problem solving a detriment to actually solving problems? The aim of this paper is to identify the core differences between shape-based and tree-based problem-solving practices, as well as their application.
===========================================================================
The structure of a shape-based problem
===========================================================================
To begin, visualize a triangle. The kind of triangle is irrelevant. For simplicity's sake; visualize an equilateral triangle. A triangle has three interconnected points that all rely on each other for continuance. Now visualize that triangle as your problem. Point X will be the problem itself. Point Y will be your idea about how to solve that problem. Point Z will be the end result when implementing your idea. Before we've even begun to idealize solving the problem, we've come to a critical flaw in this problem-solving process.
Shapes are a continuum. Point X goes to point Y goes to point Z repeated indefinitely. Do you see how that could be wrong? Shapes are indefinite. So, if you define a problem as a shape, that problem becomes indefinite. Point X may find a possible solution with Point Y. Point Y may implement that solution with point Z. Point Z, unfortunately, will only ever return to point X. When everything is said and done; you end with a collection of infinitely repeating versions of the same problem.
Say you do eventually find a solution. We then have a brand-new point A that extrudes away from point Y. But now, we don't have a shape. Rather, we have a linear tree with an integrated loop. Shapes have no end point. Trees have many end points. So, you really never will find an efficient shape to solve a problem, but you can turn a shape into a linear tree using a real solution.
====================================================================================
Perpendicularizing the process
====================================================================================
We've already created the basic principle for perpendicular problem solving. We've turned a shape into a tree. Now we need to take that concept of a tree and adapt it into a multi-functional table for solving the problem.
Consider point X as the topmost point of the tree. Point Y, in a perpendicular setting, is no longer idealizing a single solution but rather branching into points Y1 and Y2.
Fig 1: X
|
Y1--------Y-------Y2
| |
| |
Now, one thing we can do is completely reconfigure the idea of the shape. When Y1 meets point Z:
Point Z will then branch into Z1 and Z2. If Z1 becomes a shape, then the loop exit will be a return to Y1, and we can do Z2. If Z2 doesn't work, we loop back to Y1 which has no more possible pathways. That will send us on the path to Y2. We repeat this process, adding more branches in the form of Y3, Y4, etc. until a solution is found.
But why? If we're still creating a mess of shapes, how does this increase the efficiency of the problem-solving process?
The problem with individual shape-based problem solving is that you always run the risk of re-attempting something that has already failed before. Even if it looks different, it may effectively be the same thing. So, to mitigate this issue; we map a tree with many possible solutions at once. Those possible solutions are then tested sequentially, rather than just sporadically. How does that work? Well, that's why we called our sub-variables Z1 and Z2. We can assume Y1 and Y2 are two possible reasons for the problem to exist. From there, we can map multiple possible solutions to each single iteration of the problem. Z2 to Y2 would be solution 2 to possibility 2.
So the flow of events would look something like this:
X >> Y >> Y1 >> Z1 >> Y1 >> Z2 >> Y1 >> Y >> Y2 >> Z1 >>Y2 >>Z2 >> Solution.
So perpendicular problem solving isn't actually a method for replacing the loop of a shape. Rather, it's intended to be a faster method of procedurally working through each shape loop in an organized manner until a solution is found. We can even complexify the length of the tree. Say for instance Y1/Z1 is a working solution, but it introduces a brand-new problem. Let point A represent a new problem. We can connect Z1 directly to point A, which will then branch off into A1 and A2. We repeat the above process with a following B, B2/B3, continued.
Fig 2: X
|
|
|
Y1--------Y-------Y2
| Null Loop
|
|
--------Z1
|
|
|
A1--------A---------A2
| |
| |
| |
From this we see a methodical approach to the loop circuit. Yes, we are still creating shapes. But as those shapes are disqualified from the solution pool; so too are shapes disqualified from the end solution. That's the single most important property of the perpendicular method. At some point, your tree will reach an end point without a loop. Your final variable will be a working solution. Refer to Figure 2. If A2 were the final solution to problem X, then the tree branch would end without a shape, creating an endpoint.
Fig 3: x ------------------------------
| |
| |
| |
Y1--------Y-------Y2 |
| Null Loop |
| |
| |
Z1-------Z--------Z2 |
| Null Loop Implementation--Product
| |
| |
A1------A------A2 |
Null | |
Loop | |
| |
Solution ---------------------------------
From figure 3, we can see the final iteration of the process. When a solution is found, X will meet the solution for implementation. From there, we get the breakpoint Product. The structure of the final tree may well represent some kind of complex shape, but it isn't, and I'll explain why.
1: Regular shapes have a persistent start and end point. They end where they begin. This tree has an extruded end point that doesn't loop back into the shape.
2: Open-sided shapes have separate start and end points but are defined by a lack of area. They have no closure or encapsulation, and it is indeterminate whether something is inside or outside of the area of the shape. This tree forms a meeting point that creates a defined area and doesn't fit the qualifications of an open sided shape.
So what perpendicular problem-solving gives us is the containerization of multiple different problem shapes mapped across a problem-solving array. Aside from the benefit of procedurally eliminating non-possible solutions, you also get to create a reference point for similar problems where non-possible solutions may find new possibility. In conjunction; you create a definitive end point before you ever begin to map the problem at all. You know that the end point will not be a loop back into the final shape. You can also determine multiple solutions as conjunctive, creating multiple pathways to the product endpoint.
Fig 4: x ------------------------------
| |
| |
| |
Y1--------Y-------Y2 |
| Null Loop |
| |
| |
Z1-------Z--------Z2 |
| Solution---------Implementation--Product
| |
| |
A1------A------A2 |
Null | |
Loop | |
| |
Solution ---------------------------------
Figure 4 shows us a conjunctive solution state where multiple solutions were necessary or applicable to solve a single problem. The way we arrived at this solution was in one of two ways:
1: We determined that the original solution was only partially applicable, and a second solution was needed to solve a sub-problem contained within the main problem.
2: We determined that the first solution was good but decided that there may be an alternate solution of equal or greater value.
====================================================================================
Summary
====================================================================================
If you only ever consider a problem to be a two-dimensional shape, you are highly unlikely to arrive at an efficient solution. But if you consider a problem as a mappable tree with determinate pathways for every possibility; You then create an expansive testing environment to efficiently and productively solve more problems.
By creating this array of information, we now have a multi-factored and multi-tiered repository of information relating to every similar problem, as well as a framework for optimizing and expanding upon an existing solution. The beauty of that is being able to expand on your solution with existing ideas, solutions, and a relative determinate breakpoint.
Sure, you could think in a circle or a triangle or even an octahedron. But if your logic is circular, you'll always repeat yourself. So instead, think like a tree. Grow some branches and you'll grow solutions as leaves. They may fall down, but you can always grow more branches and you can always grow more leaves.