From the PCT perspective, the so-called "action" of braking is a chain of controls looking something like: [...]
Okay, thank you, that was exactly the kind of answer I was looking for, in terms of breaking down (what is framed by us non-PCTers as) a discrete list of actions into hierarchical feedback loops and what they're using for comparison. Much appreciated.
But just the same, I think your explanation illuminates my complaint about the usefulness of the model. What it appears to me is, you just took a list of discrete steps and rephrased them as continuous values. So far, so good, but all I see is added complexity. Let me explain.
I would describe my steps in baking a cake (and of course this abstracts away from lower level detail) as:
1) Open preheated oven.
2) Place pan containing batter onto middle of middle over rack.
3) Close oven.
4) Set timer.
Your claimed improvement over this framing of these events is:
1) Define variable for oven openness. Recognize it's zero and push it toward 1.
2) Define variable for pan distance from middle of middle oven rack. Recognize it's too high and push it toward zero.
3) Recognize oven openness is 1 and should be zero, push it in that direction.
4) Define variable for oven-timer-value-appropriateness. Recognize it's too low and move it higher.
Yes, superficially, you've made it all continuous, but only by positing new features of the model, like some neural mechanism isomorphic to "detection of oven-timer-value-appropriateness", which requires you to expand that out into another complex mechanism.
I agree, as I've said before, that this is one way to rephrase what is going on. But it doesn't simplify the problem; it forces you identify the physical correlate of "making sure the oven's set to the right time" in a form that I'm not convinced is appropriate for the problem. Why isn't it appropriate?
Among other things, you're forced to solve the object recognition problem and identify a format for comparison. But if I've solved the (biological) object recognition problem, my model can simply invoke the actual neural mechanism being used, without the added complexity of reformatting the causal flow into feedback loops.
You defend this model by its elegance, but you only get the elegance after you solve the problem some other way. That is, I only have an elegant hierarchical feedback loop if I can, somehow, solve the object recognition problem that allows me to actually specify a reference and feedback signal. A model isn't any good if it presupposes the solution of the problem it's being used to solve.
Hope that clarifies where I'm coming from.
I would describe my steps in baking a cake (and of course this abstracts away from lower level detail)
You could describe them that way, yes, and that would nominally describe the behaviors you emit. However, it's trivial to prove that this does not describe the implementation in your head that emits those behaviors!
For example, you might forget to preheat the oven, in which case the order of your steps is going to change. There are any number of disruptions that can occur in your sequence of "steps", that will cause you to change your action...
See this great little rationalist video here.