This is a very interesting distinction. Notably, I feel that you point better at a distinction between “search inside” and “search outside” which I waved at in my review of Abram’s post. Compared with selection vs control, this split also has the advantage that there is no recursive calls of one to the other: a controller can do selection inside, but you can’t do search-in-territory by doing search-in-map (if I understand you correctly).
That being said, I feel you haven’t yet deconfused optimization completely because you don’t give a less confused explanation of what “search” means. You point out that typically search-in-map looks more like “search/optimization algorithms” and search-in-territory looks more like “controllers”, which is basically redirecting to selection vs control. Yet I think this is where a big part of the confusion lies, because both look like search while being notoriously hard to reconcile. And I don’t think you can rely on let’s say Alex Flint’s definition of optimization, because you focus more on the internal algorithm than he does.
Key point: if we can use information to build a map before we have full information about the optimization/search task, that means we can build one map and use it for many different tasks. We can weigh all the rocks, put that info in a spreadsheet, then use the spreadsheet for many different problems: finding the rock closest in weight to a reference, finding the heaviest/lightest rock, picking out rocks which together weigh some specified amount, etc. The map is a capital investment.
One part you don’t address here is the choice of what to put in the map. In your rock example, maybe the actual task will be about finding the most beautiful rock (for some formalized notion of beautiful) which is completely uncorrelated with weight. Or one of the many different questions that you can’t answer if your map only contains the weights. So in a sense, search-in-map requires you to know the sort of info you’ll need, and what you can safely throw away.
On the thermostat example, I actually have an interesting aside from Dennett. He writes that the thermostat is an intentional system, but that the difference with humans, or even with a super advanced thermostat, is that the standard thermostat has a very abstract goal. It basically have two states and try to be in one instead of the other, by doing its only action. One consequence is that you can plug the thermostat into another room, or to control the level of water in a tub or the speed of a car, and it will do so.
From this perspective, the thermostat is not so much doing search-in-territory than search-in-map with a very abstracted map that throw basically everything.
This is a very interesting distinction. Notably, I feel that you point better at a distinction between “search inside” and “search outside” which I waved at in my review of Abram’s post. Compared with selection vs control, this split also has the advantage that there is no recursive calls of one to the other: a controller can do selection inside, but you can’t do search-in-territory by doing search-in-map (if I understand you correctly).
That being said, I feel you haven’t yet deconfused optimization completely because you don’t give a less confused explanation of what “search” means. You point out that typically search-in-map looks more like “search/optimization algorithms” and search-in-territory looks more like “controllers”, which is basically redirecting to selection vs control. Yet I think this is where a big part of the confusion lies, because both look like search while being notoriously hard to reconcile. And I don’t think you can rely on let’s say Alex Flint’s definition of optimization, because you focus more on the internal algorithm than he does.
One part you don’t address here is the choice of what to put in the map. In your rock example, maybe the actual task will be about finding the most beautiful rock (for some formalized notion of beautiful) which is completely uncorrelated with weight. Or one of the many different questions that you can’t answer if your map only contains the weights. So in a sense, search-in-map requires you to know the sort of info you’ll need, and what you can safely throw away.
On the thermostat example, I actually have an interesting aside from Dennett. He writes that the thermostat is an intentional system, but that the difference with humans, or even with a super advanced thermostat, is that the standard thermostat has a very abstract goal. It basically have two states and try to be in one instead of the other, by doing its only action. One consequence is that you can plug the thermostat into another room, or to control the level of water in a tub or the speed of a car, and it will do so.
From this perspective, the thermostat is not so much doing search-in-territory than search-in-map with a very abstracted map that throw basically everything.