[From Bruce Abbott (960115.1215 EST)]
Rick Marken (960114.1445) --
I wasn't going to be mean and claim a "gotcha" but since
you brought it up:-)
Oh, go ahead; I'm starting to get used to it.
Here's Bruce's proof that X(n) = g*X(n-1) characterizes a closed
loop system:(5) X(n) = k1*Y(n-1), and
(6) Y(n) = k2*X(n-1)
But the same result can be given by
(7) X(n) = k1*k2*X(n-1) = g*X(n-1)
The proof is obtained by substituting equation (6) into equation (5); the
equation describing Y(n) is substituted for Y(n-1) in equation (5). Of
course, this is wrong since Y(n) is not Y(n-1);
Rick, when you're right, you're right. I slipped into sequential thinking,
although I suspect this is more a result of being in the habit of writing
simulations this way than of the Freudian unconsious motives to which you
have alluded as the probable reason. By their nature, digital simulations
must handle discrete values a step at a time; they are sequential machines.
I had initially tried to deal with my pair of equations simultaneously
rather than sequentially, but got X = 0 as the steady-state solution, even
with positive feedback. This didn't seem right; positive feedback systems
should run away to their limits. So I went with the sequential analysis and
the rest is history. I really should have been indiscrete.
When you pointed out the logical error in my algebra (n is not n-1) it got
me to thinking about how it is that we are able to arive at the correct
steady-state solution for control systems in our computer simulations,
which, after all, follow the same iterative plan I used in my faulty
approach. The answer turned out, of course, to reside in the _slowing
factor_. The values in the simulation change discretely and thus jump
suddenly from iteration to iteration, whereas the real system changes
continuously. A large enough slowing factor reduces these discrete jumps
and "magically" allows the simulation to approach the correct steady-state
solution. When you add a slowing factor to one of the two equations I
presented, the system works properly and gives the closed-loop solutions to
system behavior. For positive feedback systems, a loop-gain > 1 leads to
runaway; a loop-gain < 1 converges on a stable value of zero.
Oddly enough, for the system limited at zero and some upper value Xmax, the
behavior is just as I described it, even though I screwed up my analysis of it.
Now what would happen if to this positive feedback system we added a
variable gain as I described earlier, with increases in X above some value a
leading to g < 1 and decreases below a leading to g > 1? With X above a, g
< 1 leads to a downward spiral of X; with X below a, g > 1 leads to an
accelerating increase in X. When X = a then g = 1 and the system stays put.
This is just a negative feedback system whose "reference" value is a.
Linking g to X in this way stabilizes the system.
Earlier I suggested that this might describe an equilibrium system, but I'm
not really confident in that conclusion. But it is possible to view such
systems in a simipler way, as producing a stable balance of "forces" at the
equilibrium value. This is how your leaky integrator acts to stablilize
your positive feedback system. The "leak" from the leaky integrator is an
exponential function of the size of the variable to which the integrator is
applied (call it X). As X is driven upward in the positive feedback loop (g
1), the rate at which the value of X "leaks away" is initially smaller
than its inherent rate of incrase, leading to a net increase. But if the
exponential function rises faster than the positive feedback function, at
some value of X the rate of leakage will equal the rate of input to X, and X
will neither increase nor decrease. The stable value will depend on the
rate of increase of X due to positive feedback and the size of the "hole" in
the leaky integrator's bucket.
In the engine analogy, rate-related losses in power due to such factors as
friction and cumulating inefficiency due to the increasingly limited time in
which combustion, etc. can occur play the role of your leaky integrator,
producing a stable engine rpm for a given throttle setting. But any
disturbance to the system (e.g., loading the crankshaft) will change the
balance of forces (in this case, extracting power) and lead to a different
stable value.
I'm emphatically not saying that Bruce did anything bad or malicious;
he (like any control system) was (I believe) just doing whatever was
necessary to perceive what he wanted to perceive (consistency of PCT
with conventional psychology).
I would like to propose a different explanation. Maybe, just maybe, Rick is
doing whatever is necessary to perceive what he wants to perceive (that
Bruce is trying to perceive consistency of PCT with conventional psychology).
Now, as for Rick's own analysis:
Rick Marken (960112.2330)
In order to make the loop dynamically stable I had to use a _leaky_
integrator in the output function, so that:o := o + (k.2i-o)
But doesn't this reduce to just
o := k.2i ?
If the output function is a simple integral (o := o + k.2i) then the
loop variables (o and i) go to infinity no matter what the loop gain
(unless the loop gain is 0.0).
With a simple (nonleaky) integrator in the output function you are simply
adding o to the previous sum of o on each trip around the loop. Assume that
the new value of o in an iteration (before the addition) were constant.
Then after t iterations, (starting with o at zero), o would be t*o. The
loop-gain of this system with the simple integrator is thus not k1*k2 but
rather, k1*k2*t, and this is why it goes to infinity for any k1*k2 > 0.
I can stabilize the loop with a loop gain of 1.0 or higher by making the
integrator "leak" more than it increments:o := o + (k.2i-k.3o)
And thus
o := 1*o - k.3o + k.2i = (1.0 - k.3)o + k.2i ?
Rick, you're going to have to explain your notation to me. Either I'm
reading it wrong or something is missing.
Regards,
Bruce