I’m sold on the ideas of heuristics and identifying bottlenecks in solving problems. The concepts are very generally applicable. But I’m not convinced the particular mental motions for solving mazes are the correct ones for solving problems in general.
When I’m solving a math exercise like “Show that the complement of a finite set of k points in R^n is simply-connected if n ≥ 3”, I do things like
contemplate the nature of the complement of a finite set of k points in R^n until I can visualize it and correctly answer basic questions about it, like “is it finite or infinite” and “why isn’t it simply-connected if n<3″
list all the theorems in the relevant chapter of the topology book, especially the ones that tell why sets are simply-connected (probably I need to use the van Kampen theorem, but there could be others)
think about properties of the set in question that might lead me closer to the hypotheses
repeat steps 2-3 until I develop a general plan that seems likely to work (“Show that the set is homeomorphic to a different set S; partition S into sets that satisfy the hypotheses of the van Kampen theorem; use the van Kampen theorem to show that S is simply-connected; conclude that the original set is simply-connected”)
implement the plan
There are definitely heuristics here! But in topology exercises, identifying a bottleneck as severe as a one-empty-space wall is pretty rare, and chunking is usually not possible before the problem is already almost-solved. The core steps in the solution seem to be deconfusion, forward-chaining, and back-chaining, with chunking as an incidental step and identifying a bottleneck as something to happen if you’re really lucky.
When I’m answering an open-ended question like “how do I solve alignment”, I notice the same thing, with two complications:
There is often no single obvious path, either forwards or backwards. This means we need more deconfusion and better heuristics.
I also need to do much more conscious backchaining than conscious forward-chaining, so there’s also an asymmetry between the forward and reverse searches.
But it still seems to be true that bottlenecks are hard to find deliberately. I’m guessing that the examples of bottlenecks—“programmer trying to speed up some code”, or “throughput of a factory”, have a special structure that makes bottlenecks easy to find. They are already factored into serial steps, and it’s possible to find the bottleneck just by thinking about each of the steps separately.
It sounds like your current strategies are mostly adapted to the sorts of problems found in textbooks or homework assignments—problems which are “easy” in some sense. Such problems are typically already expressed in an ontology which reduces the search-space to something reasonably small, so just listing everything, forward-chaining, and back-chaining will probably be enough. In a large search space in which solutions are rare, those methods do not have the big-O efficiency to work.
That said, many of those methods are still necessary steps even on questions with larger search spaces—for instance, visualizing the main objects in the problem.
I’m sold on the ideas of heuristics and identifying bottlenecks in solving problems. The concepts are very generally applicable. But I’m not convinced the particular mental motions for solving mazes are the correct ones for solving problems in general.
When I’m solving a math exercise like “Show that the complement of a finite set of k points in R^n is simply-connected if n ≥ 3”, I do things like
contemplate the nature of the complement of a finite set of k points in R^n until I can visualize it and correctly answer basic questions about it, like “is it finite or infinite” and “why isn’t it simply-connected if n<3″
list all the theorems in the relevant chapter of the topology book, especially the ones that tell why sets are simply-connected (probably I need to use the van Kampen theorem, but there could be others)
think about properties of the set in question that might lead me closer to the hypotheses
repeat steps 2-3 until I develop a general plan that seems likely to work (“Show that the set is homeomorphic to a different set S; partition S into sets that satisfy the hypotheses of the van Kampen theorem; use the van Kampen theorem to show that S is simply-connected; conclude that the original set is simply-connected”)
implement the plan
There are definitely heuristics here! But in topology exercises, identifying a bottleneck as severe as a one-empty-space wall is pretty rare, and chunking is usually not possible before the problem is already almost-solved. The core steps in the solution seem to be deconfusion, forward-chaining, and back-chaining, with chunking as an incidental step and identifying a bottleneck as something to happen if you’re really lucky.
When I’m answering an open-ended question like “how do I solve alignment”, I notice the same thing, with two complications:
There is often no single obvious path, either forwards or backwards. This means we need more deconfusion and better heuristics.
I also need to do much more conscious backchaining than conscious forward-chaining, so there’s also an asymmetry between the forward and reverse searches.
But it still seems to be true that bottlenecks are hard to find deliberately. I’m guessing that the examples of bottlenecks—“programmer trying to speed up some code”, or “throughput of a factory”, have a special structure that makes bottlenecks easy to find. They are already factored into serial steps, and it’s possible to find the bottleneck just by thinking about each of the steps separately.
It sounds like your current strategies are mostly adapted to the sorts of problems found in textbooks or homework assignments—problems which are “easy” in some sense. Such problems are typically already expressed in an ontology which reduces the search-space to something reasonably small, so just listing everything, forward-chaining, and back-chaining will probably be enough. In a large search space in which solutions are rare, those methods do not have the big-O efficiency to work.
That said, many of those methods are still necessary steps even on questions with larger search spaces—for instance, visualizing the main objects in the problem.