GeezerVison

coverage: 94.751% (-0.001%) from 94.752%
when pulling ce77e6b on murrayrm:update_isstatic-01Feb2025
into f73e893 on python-control:main.

I asked ChatGPT how we should think about "static". I thought the answer was pretty good:

Prompt: Consider a nonlinear input/output system with input $u$ and output $y$. What does it mean for this input/output system to be a "static" system? Is there a common definition of "static"? Also, if the system is time-dependent, is the system still considered to be static? If so, what is the logic behind that terminology?

Response: A static system in the context of input/output systems refers to a system in which the output $y(t)$ at any given time $t$ depends only on the input $u(t)$ at that same time $t$, and not on past or future values of $u$. Mathematically, this can be expressed as:

$$ y(t) = f(u(t)) $$

for some function $f$, which can be nonlinear. This means that there is no memory or dynamics involved in the system—there is no dependency on past inputs, derivatives of the input, or any internal state that evolves over time.

Common Definition of "Static"

Yes, the term "static" is commonly used in this way to distinguish such systems from dynamic systems, where the output depends on past (or future) inputs, typically via differential or difference equations.

Time-Dependent Static Systems

If the system is explicitly time-dependent, meaning that the function ($f$) varies with time, i.e.,

$$ y(t) = f(t, u(t)), $$

then the system is still often considered static because at each time $t$, the output still depends only on the instantaneous input $u(t)$. The presence of explicit time dependence does not introduce memory or dynamics into the system—it only means that the input/output relationship is changing with time.

Logic Behind the Terminology

The key idea behind calling such systems "static" is that there is no dependence on past or future inputs—no accumulation of past states, no integration, no internal state evolution. Even if the system itself changes with time, as long as the output at each moment is determined purely by the input at that moment, the system remains static in this sense.

Thus, even with explicit time dependence, a system is still called "static" if it lacks memory or dynamic behavior.

Based on that, I think we should adopt the following definition: A static I/O system model is a model in which the output $y(t)$ at any given time $t$ depends only on the input $u(t)$ at that same time $t$, and not on past or future values of $u$. Thus a static system has no internal state, but may depend on time (not an issue now, but will be if/when we add in time dependence.

Also, I've looked into where this concept is used. There are a couple of instances:

• In the describing function module, the notion of static is used in some of the initialization of the numerical computation of a describing function. There is an interesting inconsistency in the wording in this module: the docstrings say that nonlinearities have to be static, but the computations allow for non-static models (eg, hysteresis).
• When computing out the timebase dt, if a system is static then not specifying a timebase allows the timebase to default to None, which means it can be combined with either a continuous or discrete time system. This only occurs when a system is created.
• In various places we need to handle the case with nstates == 0 separately, since it means that things like eigenvalues of the A matrix don't exist. Those might be as easily handled by a direct check on what we care about (A.size == 0).
  I'll think through these and update the PR to provide a more uniform way of representing static I/O systems (including describing functions).

Looks good, with just a couple of clarifying questions.

I asked ChatGPT how we should think about "static". I thought the answer was pretty good:

Nice. and pretty good answer.

It looks like Matlab has an isstatic function, perhaps a future PR could turn _isstatic into a public method.

I thought about making isstatic public, but I couldn't think if where you might want to actually use it in "user" code. Easy enough to change. Is there a use case that could motivate making it public?