Her baking post was in the back of my mind when I typed my last comment! I thought it was great. I had the same reaction to her post as I had to yours.
We can and often do use constraints to guide our optimization process. Here are some examples:
When choosing a hobby, we can brainstorm what we want to get out of our hobby before we consider concrete activities that fit the bill.
When solving on a math problem, we can invent some rules for how to format our work so that it’ll be legible later.
Yelp implicitly considers factors like price, location, quality, and type of food before giving us options.
When building a bridge, we’re going to use standardized materials, tools, and techniques, not invent our own.
These constraints might be selected through intuition, or through the design of meta-constraints that help us select which object-level constraints to use.
However, the idea behind each constraint had to be invented in the first place, and in any concrete decision, we have to improvise its application.
So how does a constraint get invented in the first place? How do we decide which ones to use for a given decision? And how do we decide how to apply them? Probably with more constraints, but then the same questions arise about those. At some point, we are just picking constraints at random from those that occur to us, choosing randomly from among options that fit them, and seeing how we feel about the result.
We associate good feelings with individual or combinations of constraints that have worked out well in the past or that we’ve been taught to use, so they’re more likely to occur to us in the future.
So the process by which we decompose a problem; invent, combine, and apply constraints; or decide how to evaluate a decision; is itself a random process. Plan it all out, and you move the randomness one meta-level higher. That’s not to say it’s pointless. Planning and meta-level reasoning is often a powerful way to make decisions. It’s just not fundamentally different from object-level explore/exploit, and it runs into similar problems and ambiguities, just on a more abstract level.
I think your description here is basically right, except for the very last sentence. If we just had one meta-level, then yeah, it would end up basically the same as explore/exploit but at a more abstract level. But by recursively applying the trick, it ends up working well on a much wider class of problems than explore/exploit by itself.
The really neat thing is that recursively applying this particular trick does not require moving up an infinite ladder of meta-levels. There are only two levels, and moving “up” alternates between them.
To see why, consider what it looks like on a math problem where we’re trying to prove some theorem:
A “constraint” would be something like a conditional counterexample—i.e. “for any proof which uses strategy X, here’s a counterexample”
When searching for such counterexamples, our “constraints” are partial proofs—i.e. if we have a proof assuming X, then any counterexample must leverage/assume the falsehood of X.
So when we use constraints to guide our search for proofs, we look for counterexamples. When we use constraints to guide our search for counterexamples, we look for proofs.
More visually, consider solving a maze. We can find constraints like this:
When we’re searching for that constraint, what are the meta-constraints to that search? Well, they’re paths. A constraint is a path of connected walls; a meta-constraint is a path of connected spaces.
In general, we’re switching between solving an optimization problem and solving the dual problem.
Of course, we may also use some random search at any given step before switching.
Her baking post was in the back of my mind when I typed my last comment! I thought it was great. I had the same reaction to her post as I had to yours.
We can and often do use constraints to guide our optimization process. Here are some examples:
When choosing a hobby, we can brainstorm what we want to get out of our hobby before we consider concrete activities that fit the bill.
When solving on a math problem, we can invent some rules for how to format our work so that it’ll be legible later.
Yelp implicitly considers factors like price, location, quality, and type of food before giving us options.
When building a bridge, we’re going to use standardized materials, tools, and techniques, not invent our own.
These constraints might be selected through intuition, or through the design of meta-constraints that help us select which object-level constraints to use.
However, the idea behind each constraint had to be invented in the first place, and in any concrete decision, we have to improvise its application.
So how does a constraint get invented in the first place? How do we decide which ones to use for a given decision? And how do we decide how to apply them? Probably with more constraints, but then the same questions arise about those. At some point, we are just picking constraints at random from those that occur to us, choosing randomly from among options that fit them, and seeing how we feel about the result.
We associate good feelings with individual or combinations of constraints that have worked out well in the past or that we’ve been taught to use, so they’re more likely to occur to us in the future.
So the process by which we decompose a problem; invent, combine, and apply constraints; or decide how to evaluate a decision; is itself a random process. Plan it all out, and you move the randomness one meta-level higher. That’s not to say it’s pointless. Planning and meta-level reasoning is often a powerful way to make decisions. It’s just not fundamentally different from object-level explore/exploit, and it runs into similar problems and ambiguities, just on a more abstract level.
I think your description here is basically right, except for the very last sentence. If we just had one meta-level, then yeah, it would end up basically the same as explore/exploit but at a more abstract level. But by recursively applying the trick, it ends up working well on a much wider class of problems than explore/exploit by itself.
The really neat thing is that recursively applying this particular trick does not require moving up an infinite ladder of meta-levels. There are only two levels, and moving “up” alternates between them.
To see why, consider what it looks like on a math problem where we’re trying to prove some theorem:
A “constraint” would be something like a conditional counterexample—i.e. “for any proof which uses strategy X, here’s a counterexample”
When searching for such counterexamples, our “constraints” are partial proofs—i.e. if we have a proof assuming X, then any counterexample must leverage/assume the falsehood of X.
So when we use constraints to guide our search for proofs, we look for counterexamples. When we use constraints to guide our search for counterexamples, we look for proofs.
More visually, consider solving a maze. We can find constraints like this:
When we’re searching for that constraint, what are the meta-constraints to that search? Well, they’re paths. A constraint is a path of connected walls; a meta-constraint is a path of connected spaces.
In general, we’re switching between solving an optimization problem and solving the dual problem.
Of course, we may also use some random search at any given step before switching.