update use/computation of sys._isstatic() #1117

murrayrm · 2025-02-02T06:41:38Z

This small PR addresses #1090, where there was a redundant calculation for whether a transfer function is static (constant) or not. This fixes that by saving the computation done in init and using it later if sys._isstatic() is called. I also found a spot in nlsys where there was a (simple) redundant computation, so converted that to a call to sys._isstatic().

Following the discussion below, the current PR does the following:

Moves the _isstatic() method from InputOutputSystem to NonlinearIOSystem and TransferFunction. This is because the way in which the checks are done is different for systems with a state versus transfer functions.
For NonlinearIOSystem (including StateSpace, which is a subclass), a system sys is static if sys.nstates is zero, so this is what _isstatic() checks.
For TransferFunction, a system sys is static if the numerator and denominator polynomials are all zero order. This is computed when the system is constructed and store in the private instance variable _static.
For FrequencyResponseData, the _isstatic() method is not defined (mainly because it isn't used anywhere).
Updated the User Guide documentation for nonlinear systems to reflect the updated usage of "static" (= no internal state, but time-varying is allowed).
Updated the documentation and docstrings for describing functions to reflect that fact that non-static functions are allowed (eg, backlash and hysteresis).

The main uses of the static property for a system are described in more detail in the comments below.

coveralls · 2025-02-02T06:56:19Z

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

sawyerbfuller

This looks good. But a question that comes to mind is should tf’s new _isstatic method get put in iosys.py instead (and the explanatory comment moved to its init)? If so, I think NonlinearIOSystem should also get a _static field. Statesp.py also suffers from multiple implementations of isstatic (the first when the dt field is processed in process_io_keywords) but this may just be unavoidable complexity.

One thing to consider is terminology : is a time-varying stateless system considered to be static?

control/xferfcn.py

murrayrm · 2025-02-03T18:57:52Z

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.

murrayrm · 2025-02-03T19:37:05Z

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).

sawyerbfuller · 2025-02-04T23:55:48Z

Looks good, with just a couple of clarifying questions.

sawyerbfuller · 2025-02-04T23:57:56Z

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.

murrayrm · 2025-02-05T01:35:29Z

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?

murrayrm linked an issue Feb 2, 2025 that may be closed by this pull request

Remove redundant _isstatic calculation in xferfcn #1090

Closed

murrayrm requested a review from sawyerbfuller February 2, 2025 06:59

sawyerbfuller requested changes Feb 2, 2025

View reviewed changes

sawyerbfuller reviewed Feb 3, 2025

View reviewed changes

control/xferfcn.py Outdated Show resolved Hide resolved

murrayrm added 3 commits February 3, 2025 22:38

update use/computation of sys._isstatic()

b9ba9ae

update describing terminology on "static"

8cdc09a

clean up terminology and checks for "static" systems

ce77e6b

murrayrm force-pushed the update_isstatic-01Feb2025 branch from d99ac61 to ce77e6b Compare February 4, 2025 06:38

murrayrm merged commit cf77f99 into python-control:main Feb 8, 2025
24 checks passed

murrayrm added this to the 0.10.2 milestone Feb 19, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

update use/computation of sys._isstatic() #1117

update use/computation of sys._isstatic() #1117

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Common Definition of "Static"

Time-Dependent Static Systems

Logic Behind the Terminology

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

update use/computation of sys._isstatic() #1117

update use/computation of sys._isstatic() #1117

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Common Definition of "Static"

Time-Dependent Static Systems

Logic Behind the Terminology

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!