[Hans Blom, 970306b]
(Martin Taylor 970304 10:50)
To quote you: I think we have settled the question: one-jump error
correction is entirely possible and quite normal in physical
systems.
I'm thoroughly mystified. In a physical system, what is "dt" that
defines "one-jump"? Is it the supposed quantal unit of time, 10^-43
seconds?
Of course not. It is an artifact that is introduced by our use of
computers, or rather by our desire to write programs in computer
languages that cannot handle differential equations. These have to be
transformed into difference equations if an inappropriate language
such as Pascal is used. The conversion from differential equation to
difference equation necessarily introduces a dt and, frequently, an
approximation and thus a computation artifact. The latter can be a
great source of confusion. It is therefore recommended, if one uses
classical programming languages, to use exact methods that introduce
no computation artifacts. These are not generally known, however.
Thus one can encounter frequent vehement arguments about whether a
computer display shows something that correctly corresponds with
reality or whether some phenomenon is introduced by an approximation
due to the algorithm used. Regrettably, this often can be discovered
only through a rigorous analysis of what the program code "means".
Using an analog simulation language such as Simcon, Tutsim or Matlab
would greatly alleviate these problems; although these also work with
difference equations internally, they take care of the dt problem,
e.g. by choosing an appropriate value dynamically, "on the fly". One
must hope that they do so correctly.
As you see, I'm very reluctant to accept programs and simulations as
"proofs"...
I was under the impression that we usually considered time to be a
continuous variable on the scales with which we usually work. Where
does an instantaneous jump appear in physical systems of classical
scale?
That is an interesting question but not relevant here. The "one jump"
refers to expressions such as
x(t+dt) := x(t) + ...
where there is a "time jump" from time t to time t+dt, and where we
are not interested in -- and indeed cannot describe -- what happens
to x in between. We usually assume that "nothing interesting" happens
in between. That can be tested, in practice, by choosing a different
dt (e.g. half or double the original value) and checking that nothing
significant changes. If we known the signal bandwidths a priori, we
can use Shannon's sampling theorem to derive an appropriate value for
dt.
The "one" refers to a _single_ time interval dt. During a small time
interval dt one obviously cannot do too much...
Much of the PCT-MCT comparison discussion centers around the strange
way (to me! to you it may be the familiar way...) in which PCT
specifies goals. The PCT way of specifying goals is appropriate only
in stabilization, i.e. when the reference value remains constant;
then the "one jump" approach is entirely appropriate. But usually not
when the reference value changes abruptly and greatly -- in practice
not when the controller's output saturates. The theodolite, for
instance, was initially specified to go from position x=0 to x=1
(radians) immediately (in "one jump"). This is, of course, not
possible. It is interesting, however, to analyze how the controller
will interpret this command. One can show that it will "understand"
that it must go to x=1 as rapidly as possible, and "damn the
consequences" (which may result in very undesirable "unintended side
effects" like severe overshoots).
MCT controllers therefore often specify a "goal trajectory", i.e.
they plan ahead. This can be done, for instance, by designing a
control law that is based on an error criterium such as
t=T2
integral [ x(t)-r(t)^2 ] dt
t=T1
which commands the controller to minimize the total error over a
_time interval_ rather than just at a single instant. Doing so can be
interpreted as creating another level; it will generate action plans
that will prevent severe overshoots and oscillations but may make the
approach to target somewhat slower. Seen in this light, "planning" is
"on the fly" construction of a reference level trajectory, to be
adjusted after every new observation -- pretty much as the higher
hierarchical levels of an HPCT controller do for the lower levels.
But I'm sure I'm not telling you anything new...
Greetings,
Hans