SysIdentPy: NARMAX System Identification in Python

The gap SysIdentPy fills between ARIMA and a neural network

Most time series libraries assume the model is a function of past values of the series alone. SysIdentPy assumes the model is a function of past inputs and past outputs, which is the NARMAX formulation, and it makes that assumption explicit in the API. The README lists the variants it covers: NARX, NARMA, NAR, NFIR, ARMAX, ARX, ARMA and others. That list matters because the choice between them is a modelling decision about which terms are allowed into the regression, not a hyperparameter you tune.

The audience is narrow but well defined. The pyproject classifiers say Scientific/Research and Information Technology, and the package description calls it a package for system identification using NARMAX models. If you are identifying a plant, a damper, an aircraft or an electric device from logged input and output, this is the vocabulary you already use. If you are forecasting retail demand from a single column of numbers, the input-output framing will feel like overhead.

Model structure selection is the actual product

The hard part of NARMAX is not fitting coefficients. It is deciding which candidate terms belong in the model. A second order model with a handful of lags produces hundreds of candidate monomials, and ordinary least squares will happily fit all of them. SysIdentPy's answer is a family of structure selection algorithms, and the README names them: FROLS, MetaMSS, AOLS, UOFR, Entropic Regression, RMSS, and Orthogonal Floating Search in its OSF, OIF and OOS/O2S forms. Each is paired with parameter estimation methods, of which the README says there are more than fifteen.

That pairing is the design. Structure selection picks the terms, parameter estimation fits them, and the two are separable so you can hold the term set fixed and swap estimators. The README also mentions a SimulateNARMAX class for reproducing published models and comparing estimation methods against them. That is an unusual feature: it treats a paper's reported model as an input you can re-run rather than a result you can only cite.

Basis functions are the other lever. The README says up to eight basis functions can be combined, and names Polynomial, Fourier and Bilinear in the Array API section, with a custom-basis-function example in the repository. So the regressor space is not fixed to monomials of lagged inputs and outputs.

Installing SysIdentPy and fitting a first NARX model

The README gives one installation command. It pulls the package from PyPI:

pip install sysidentpy

The same section lists the requirements: Python 3.10 or newer, NumPy 1.19.2 or newer, Matplotlib 3.3.2 or newer, PyTorch 1.7.1 or newer for NARX neural networks, and SciPy 1.8.0 or newer. pyproject.toml pins the interpreter range more tightly at >=3.10,<3.16. Linux, Windows and macOS are all listed as supported, and the README notes that some examples need extra packages such as pandas.

The repository ships notebooks under examples/. The names tell you what is covered without opening them: general-NARX-models.ipynb, model-with-multiple-inputs.ipynb, aols-overview.ipynb, basis-function-overview.ipynb, information-criteria-overview.ipynb, create-a-narx-neural-network.ipynb, and application notebooks for an F-16 aircraft, a magneto-rheological damper, a coupled electric device and photovoltaic forecasting. Start with general-NARX-models.ipynb rather than the domain notebooks, because the domain ones assume you already know the NARMAX API.

If you want to try the newer dispatch behaviour, the README documents two entry points. Both are opt-in, so nothing changes unless you ask for it:

from sysidentpy.config import set_config, config_context

set_config(array_api_dispatch=True)

with config_context(array_api_dispatch=True):
    ...

The README is explicit that this is experimental. Backend-native support currently covers the supported model structure selection algorithms, simulation, metrics, utilities, and the Polynomial, Fourier and Bilinear basis functions. Coverage is described as strongest for NumPy, PyTorch and array_api_strict, with CuPy and JAX described as experimental compatibility targets.

The limitation worth reading twice is in the same paragraph. On non-NumPy backends, one-step prediction stays backend-native, but sequential prediction, meaning steps_ahead=None or steps_ahead greater than 1, runs through a NumPy/CPU fallback and converts predictions back to the original namespace and device. So the multi-step path you probably care about in forecasting is the one that leaves the accelerator. The README points to an Array API dispatch guide for the exact support matrix.

Where SysIdentPy is the wrong tool

The library is built on NumPy and the README states that plainly. There is no mention of GPU-native training for the classical estimators, no distributed fitting, and no streaming or online update path. If your model has to be refit on a rolling window inside a low-latency service, the fit cost of a structure selection search over a large candidate term set is the constraint, and nothing in the README suggests that cost has been addressed.

The Array API fallback is the second boundary. Enabling dispatch does not make sequential simulation backend-native, so a PyTorch tensor input does not guarantee an accelerator-resident forecast. A user who turns on dispatch expecting end-to-end device execution will be surprised by the conversion back.

The third boundary is scope. The README frames everything around dynamic systems with inputs and outputs. There is no classification API, no text or image handling, and the keywords list time-series-classification, but the feature table describes model building, structure selection, basis functions, parameter estimation and simulation. Treat the classification keyword as a tag, not a documented workflow.

Finally, the README does not document rollback or a deprecation policy for the Array API configuration. If you adopt set_config(array_api_dispatch=True) in a library that others import, you are opting them into experimental behaviour with no stated exit path beyond turning it off.

SysIdentPy against Sindy and N4SID in Python

The closest alternative in spirit is Sindy, sparse identification of nonlinear dynamics. Both fit a library of candidate nonlinear terms and both prefer sparse solutions. The difference is the library and the target. Sindy typically builds terms from a state vector and its derivatives, which suits ODE discovery from simulation or clean measurements. SysIdentPy builds terms from lagged inputs and outputs, which suits sampled input-output data from a plant where you never observe the full state. That is why SysIdentPy's variants are named after the lag structure, ARX, ARMAX, NARX, and Sindy's are not.

N4SID, which appears in the related searches, is a subspace identification method. It estimates a state space realization directly from input-output data by projecting onto subspaces, and it does not require you to enumerate candidate terms. The trade-off runs the other way: N4SID gives you matrices you then have to interpret, while SysIdentPy gives you a difference equation you can read term by term. If you need a controller-oriented state space model and you have enough data for the projections to be well conditioned, N4SID is the more direct route. If you need to explain which lagged product drives the output, SysIdentPy's output is closer to the answer.

The practical difference in effort is that SysIdentPy asks you to choose an information criterion and a maximum lag before you start, and those two choices shape the result more than the estimator does. The information-criteria-overview.ipynb example exists precisely because that choice is not automatic.

Licence, releases and what maintenance costs you

SysIdentPy is distributed under the 3-Clause BSD licence, confirmed in both the README badges and the pyproject classifier. BSD-3-Clause permits commercial use and modification provided the copyright notice and disclaimer are retained, and it does not carry the patent grant that Apache-2.0 does. That last point is a real difference if you are shipping in a patent-sensitive domain, and it is a reason some legal teams prefer Apache-2.0 for a dependency. This is a description of the licence text, not legal advice; read LICENSE in the repository and route the question to whoever handles licensing where you work.

The release cadence visible in the repository is roughly three to four months between minor versions, with v0.9.0 on 2026-06-13, v0.8.0 on 2026-03-28 and v0.7.0 on 2025-11-30. The last push to the default branch was on 2026-08-12. The repository is not archived. Minor-version jumps of this size mean the upgrade cost is not zero: the Array API configuration is described as experimental, and experimental surfaces are the ones most likely to move between releases. Pin the version in your dependency file and read CHANGELOG.md before bumping, rather than tracking the latest release automatically.

Editorial conclusion

Adopt SysIdentPy if you need a parsimonious difference equation you can read, simulate and defend in a report, and if your data comes from a dynamic system rather than an independent sample. Skip it if you want a drop-in replacement for a gradient boosted tree on tabular regression, or if you need a maintained GUI. Before committing, run your own data through FROLS with a fixed lag and confirm the selected terms survive a change in the information criterion, because the README documents the methods but not how stable their selections are across criteria.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. wilsonrljr/sysidentpy on GitHub