tsdynamics 5.2.5__tar.gz → 5.2.6__tar.gz

tsdynamics-5.2.6/PKG-INFO

@@ -0,0 +1,221 @@
+Metadata-Version: 2.4
+Name: tsdynamics
+Version: 5.2.6
+Classifier: Development Status :: 4 - Beta
+Classifier: Intended Audience :: Science/Research
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Scientific/Engineering :: Mathematics
+Classifier: Topic :: Scientific/Engineering :: Physics
+Classifier: Typing :: Typed
+Requires-Dist: numpy>=2.0,<3.0
+Requires-Dist: scipy>=1.14,<2.0
+Requires-Dist: symengine>=0.13,<1.0
+Requires-Dist: sympy>=1.13,<2.0
+Requires-Dist: plotly>=6,<7 ; extra == 'interactive'
+Requires-Dist: lzcomplexity>=0.9 ; extra == 'lz'
+Requires-Dist: matplotlib>=3.9,<5 ; extra == 'plot'
+Requires-Dist: matplotlib>=3.9,<5 ; extra == 'viz'
+Provides-Extra: interactive
+Provides-Extra: lz
+Provides-Extra: plot
+Provides-Extra: viz
+License-File: LICENSE
+Summary: Zero-warmup Rust-engine ODE/DDE/SDE integration, discrete maps, and chaos analysis for dynamical systems.
+Keywords: dynamical systems,ODE,DDE,chaos,Lyapunov exponents,nonlinear dynamics,bifurcation,attractors,reservoir computing
+Author-email: Daniel Estevez <kemossabee@gmail.com>
+License-Expression: MIT
+Requires-Python: >=3.12, <4.0
+Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM
+Project-URL: Changelog, https://github.com/El3ssar/TSDynamics/releases
+Project-URL: Documentation, https://el3ssar.github.io/TSDynamics/
+Project-URL: Issues, https://github.com/El3ssar/TSDynamics/issues
+Project-URL: Source, https://github.com/El3ssar/TSDynamics
+
+# TSDynamics
+
+[![Python](https://img.shields.io/pypi/pyversions/tsdynamics)](https://pypi.org/project/tsdynamics/)
+[![CI](https://github.com/El3ssar/TSDynamics/actions/workflows/ci.yml/badge.svg)](https://github.com/El3ssar/TSDynamics/actions/workflows/ci.yml)
+[![Release](https://github.com/El3ssar/TSDynamics/actions/workflows/release.yml/badge.svg)](https://github.com/El3ssar/TSDynamics/actions/workflows/release.yml)
+[![Docs](https://github.com/El3ssar/TSDynamics/actions/workflows/docs.yml/badge.svg)](https://el3ssar.github.io/TSDynamics/)
+[![PyPI](https://img.shields.io/pypi/v/tsdynamics)](https://pypi.org/project/tsdynamics/)
+[![codecov](https://codecov.io/gh/El3ssar/TSDynamics/graph/badge.svg)](https://codecov.io/gh/El3ssar/TSDynamics)
+
+**Dynamical systems in Python: 151 built-in systems, a native Rust integration
+engine, and a chaos-analysis toolkit — with the simplest system-definition
+contract anywhere.**
+
+You write the math (one symbolic method); TSDynamics lowers it to a native Rust
+engine and handles integration, Lyapunov spectra, bifurcation diagrams, Poincaré
+sections, attractors & basins — and even the documentation page for your system.
+
+<p align="center">
+  <img src="docs/assets/readme/lorenz_spin.gif" width="440" alt="A spinning Lorenz attractor"><br>
+  <em>A built-in Lorenz attractor — integrated, spun, and saved to a GIF (code below).</em>
+</p>
+
+```python
+import tsdynamics as ts
+
+lor = ts.Lorenz()
+traj = lor.integrate(final_time=100.0, dt=0.01)
+traj["x"]                              # named component access
+lor.lyapunov_spectrum()                # → [0.91, ~0, -14.57]
+ts.kaplan_yorke_dimension(_)           # → ~2.06
+```
+
+📖 **Documentation: <https://el3ssar.github.io/TSDynamics/>**
+
+---
+
+## Define your own system
+
+```python
+import tsdynamics as ts
+
+class Rossler(ts.ContinuousSystem):
+    params = {"a": 0.2, "b": 0.2, "c": 5.7}
+    dim = 3
+    variables = ("x", "y", "z")            # optional niceties
+
+    @staticmethod
+    def _equations(y, t, *, a, b, c):
+        x, yv, z = y(0), y(1), y(2)
+        return (-yv - z, x + a * yv, b + z * (x - c))
+```
+
+That's the whole contract. The class auto-registers: every analysis tool works
+on it, the test-suite sweeps it, and the docs build renders its equations
+(LaTeX, straight from the symbolics) and its attractor — zero extra steps. Delay
+systems use `y(0, t - tau)`; maps implement `_step`/`_jacobian` (signature order
+validated at import); SDEs add a `_diffusion` term.
+
+## From equations to figures
+
+Every system produces a `Trajectory`, and every `Trajectory` knows how to plot
+itself (`to_plot_spec` auto-detects the right kind from the data). The plot is a
+backend-neutral *spec* you tweak fluently, then `render` or `save` to matplotlib,
+plotly (interactive), or a three.js / JSON export.
+
+**Bifurcation diagram of the logistic map**, with the period-doubling onsets
+marked — `orbit_diagram` is one call, and `.bifurcation_points()` finds the
+cascade ($r_1 = 3$, $r_2 = 1 + \sqrt6 \approx 3.449$, …):
+
+```python
+import numpy as np, tsdynamics as ts
+from tsdynamics.viz import Annotation
+
+orbit = ts.orbit_diagram(ts.Logistic(), "r", np.linspace(2.8, 4.0, 2000))
+pts = orbit.bifurcation_points()
+
+spec = orbit.to_plot_spec().relabel(x="r", y="x*", title="Logistic bifurcation")
+spec.style(color="k", s=0.2, alpha=0.5)                  # tiny semi-transparent dots
+spec.annotations = [
+    Annotation("vline", x=pts[i], text=lbl, style={"color": "red", "linestyle": "--"})
+    for i, lbl in [(0, " r₁"), (1, " r₂"), (3, " r₄")]
+]
+spec.save("bifurcation.png", size=(1600, 700))
+```
+
+![Logistic bifurcation diagram](docs/assets/readme/logistic_bifurcation.png)
+
+**A PDE, too** — the Kuramoto–Sivashinsky equation is a built-in spatially
+extended system; its space–time field is auto-detected and drawn as a heatmap:
+
+```python
+ks = ts.KuramotoSivashinsky(N=128, L=22.0)
+traj = ks.integrate(final_time=200.0, dt=0.25)
+traj.to_plot_spec().save("ks.png")        # 128-mode space–time field
+```
+
+
+
+<p align="center">
+  <img src="docs/assets/readme/ks_spacetime.png" alt="Kuramoto–Sivashinsky space–time field">
+</p>
+
+
+The spinning attractor at the top is the same `to_plot_spec`, animated:
+
+```python
+traj = ts.Lorenz().integrate(final_time=100.0, dt=0.01)
+spec = traj.to_plot_spec()
+spec.style(axes=False).trail(None).camera(spin=0.4)      # full curve, no axes, rotate
+spec.animate(fps=30, duration=10, loop=True)
+spec.save("lorenz.gif")
+```
+
+## A taste of the analysis layer
+
+```python
+import numpy as np, tsdynamics as ts
+
+# Poincaré section of the Rössler attractor (root-refined crossings)
+section = ts.poincare_section(ts.Rossler(), plane=("y", 0.0, "up"), n=500)
+
+# Fixed points of the Hénon map, with stability
+ts.fixed_points(ts.Henon())
+# [FixedPoint([-1.1314 -0.3394], unstable), FixedPoint([0.6314 0.1894], unstable)]
+
+# Maximal Lyapunov exponent — no Jacobian needed
+ts.max_lyapunov(ts.Lorenz(ic=[1, 1, 1]), dt=0.05)        # ≈ 0.9
+```
+
+Plus: **attractors & basins** of any flow or map, correlation/Rényi **fractal
+dimensions**, **permutation/sample/dispersion entropy**, **RQA** (recurrence
+quantification), **surrogate** hypothesis tests, **delay embedding** (Takens,
+optimal τ, Cao/FNN), GALI & the 0–1 chaos test, and Lyapunov exponents **from a
+bare time series** (Kantz/Rosenstein).
+
+## Highlights
+
+- **Three families, one interface**
+
+  - **ODEs**
+
+  - **DDEs**
+  - **SDEs**
+  - **Discrete Maps**
+
+- **151 built-in systems** with literature parameters.
+
+- **Native engine**: equations lower to a Rust engine (an SSA-tape
+  interpreter, with a Cranelift JIT alongside) in-process; parameters are runtime
+  values, so changing them is free and there is no compile step or cache.
+
+- **Composition** — a `PoincareMap` of a flow *is* a discrete map, so
+  `orbit_diagram(PoincareMap(Rossler(), ("y", 0.0)), "c", values)` draws the
+  bifurcation diagram of a *flow* in one line.
+
+- **Backend-neutral plotting** — one `PlotSpec` IR renders to matplotlib, plotly
+  (interactive + animated HTML), three.js, or JSON, with a fluent styling/theming
+  vocabulary.
+
+## Install
+
+```bash
+pip install tsdynamics            # or: uv add tsdynamics
+```
+
+A prebuilt `abi3` wheel (manylinux / musllinux / macOS / Windows) bundles the
+native Rust engine. No Rust toolchain and no C compiler needed to install or
+run. Optional plotting extra: `tsdynamics[plot,interactive]` (matplotlib, plotly).
+
+## Development
+
+```bash
+git clone https://github.com/El3ssar/TSDynamics && cd TSDynamics
+uv sync --group dev --group docs
+uv run pytest -m "not slow" --no-cov     # fast tier
+uv run pytest --no-cov                   # full local suite
+TSD_DOCS_FIGURES=0 uv run mkdocs serve   # docs preview
+```
+
+Releases are automated: conventional-commit PR titles drive
+[semantic-release](https://python-semantic-release.readthedocs.io/) on merge see [CONTRIBUTING](https://el3ssar.github.io/TSDynamics/project/contributing/).
+
+## License
+
+MIT © Daniel Estevez
+

tsdynamics-5.2.6/README.md

@@ -0,0 +1,185 @@
+# TSDynamics
+
+[![Python](https://img.shields.io/pypi/pyversions/tsdynamics)](https://pypi.org/project/tsdynamics/)
+[![CI](https://github.com/El3ssar/TSDynamics/actions/workflows/ci.yml/badge.svg)](https://github.com/El3ssar/TSDynamics/actions/workflows/ci.yml)
+[![Release](https://github.com/El3ssar/TSDynamics/actions/workflows/release.yml/badge.svg)](https://github.com/El3ssar/TSDynamics/actions/workflows/release.yml)
+[![Docs](https://github.com/El3ssar/TSDynamics/actions/workflows/docs.yml/badge.svg)](https://el3ssar.github.io/TSDynamics/)
+[![PyPI](https://img.shields.io/pypi/v/tsdynamics)](https://pypi.org/project/tsdynamics/)
+[![codecov](https://codecov.io/gh/El3ssar/TSDynamics/graph/badge.svg)](https://codecov.io/gh/El3ssar/TSDynamics)
+
+**Dynamical systems in Python: 151 built-in systems, a native Rust integration
+engine, and a chaos-analysis toolkit — with the simplest system-definition
+contract anywhere.**
+
+You write the math (one symbolic method); TSDynamics lowers it to a native Rust
+engine and handles integration, Lyapunov spectra, bifurcation diagrams, Poincaré
+sections, attractors & basins — and even the documentation page for your system.
+
+<p align="center">
+  <img src="docs/assets/readme/lorenz_spin.gif" width="440" alt="A spinning Lorenz attractor"><br>
+  <em>A built-in Lorenz attractor — integrated, spun, and saved to a GIF (code below).</em>
+</p>
+
+```python
+import tsdynamics as ts
+
+lor = ts.Lorenz()
+traj = lor.integrate(final_time=100.0, dt=0.01)
+traj["x"]                              # named component access
+lor.lyapunov_spectrum()                # → [0.91, ~0, -14.57]
+ts.kaplan_yorke_dimension(_)           # → ~2.06
+```
+
+📖 **Documentation: <https://el3ssar.github.io/TSDynamics/>**
+
+---
+
+## Define your own system
+
+```python
+import tsdynamics as ts
+
+class Rossler(ts.ContinuousSystem):
+    params = {"a": 0.2, "b": 0.2, "c": 5.7}
+    dim = 3
+    variables = ("x", "y", "z")            # optional niceties
+
+    @staticmethod
+    def _equations(y, t, *, a, b, c):
+        x, yv, z = y(0), y(1), y(2)
+        return (-yv - z, x + a * yv, b + z * (x - c))
+```
+
+That's the whole contract. The class auto-registers: every analysis tool works
+on it, the test-suite sweeps it, and the docs build renders its equations
+(LaTeX, straight from the symbolics) and its attractor — zero extra steps. Delay
+systems use `y(0, t - tau)`; maps implement `_step`/`_jacobian` (signature order
+validated at import); SDEs add a `_diffusion` term.
+
+## From equations to figures
+
+Every system produces a `Trajectory`, and every `Trajectory` knows how to plot
+itself (`to_plot_spec` auto-detects the right kind from the data). The plot is a
+backend-neutral *spec* you tweak fluently, then `render` or `save` to matplotlib,
+plotly (interactive), or a three.js / JSON export.
+
+**Bifurcation diagram of the logistic map**, with the period-doubling onsets
+marked — `orbit_diagram` is one call, and `.bifurcation_points()` finds the
+cascade ($r_1 = 3$, $r_2 = 1 + \sqrt6 \approx 3.449$, …):
+
+```python
+import numpy as np, tsdynamics as ts
+from tsdynamics.viz import Annotation
+
+orbit = ts.orbit_diagram(ts.Logistic(), "r", np.linspace(2.8, 4.0, 2000))
+pts = orbit.bifurcation_points()
+
+spec = orbit.to_plot_spec().relabel(x="r", y="x*", title="Logistic bifurcation")
+spec.style(color="k", s=0.2, alpha=0.5)                  # tiny semi-transparent dots
+spec.annotations = [
+    Annotation("vline", x=pts[i], text=lbl, style={"color": "red", "linestyle": "--"})
+    for i, lbl in [(0, " r₁"), (1, " r₂"), (3, " r₄")]
+]
+spec.save("bifurcation.png", size=(1600, 700))
+```
+
+![Logistic bifurcation diagram](docs/assets/readme/logistic_bifurcation.png)
+
+**A PDE, too** — the Kuramoto–Sivashinsky equation is a built-in spatially
+extended system; its space–time field is auto-detected and drawn as a heatmap:
+
+```python
+ks = ts.KuramotoSivashinsky(N=128, L=22.0)
+traj = ks.integrate(final_time=200.0, dt=0.25)
+traj.to_plot_spec().save("ks.png")        # 128-mode space–time field
+```
+
+
+
+<p align="center">
+  <img src="docs/assets/readme/ks_spacetime.png" alt="Kuramoto–Sivashinsky space–time field">
+</p>
+
+
+The spinning attractor at the top is the same `to_plot_spec`, animated:
+
+```python
+traj = ts.Lorenz().integrate(final_time=100.0, dt=0.01)
+spec = traj.to_plot_spec()
+spec.style(axes=False).trail(None).camera(spin=0.4)      # full curve, no axes, rotate
+spec.animate(fps=30, duration=10, loop=True)
+spec.save("lorenz.gif")
+```
+
+## A taste of the analysis layer
+
+```python
+import numpy as np, tsdynamics as ts
+
+# Poincaré section of the Rössler attractor (root-refined crossings)
+section = ts.poincare_section(ts.Rossler(), plane=("y", 0.0, "up"), n=500)
+
+# Fixed points of the Hénon map, with stability
+ts.fixed_points(ts.Henon())
+# [FixedPoint([-1.1314 -0.3394], unstable), FixedPoint([0.6314 0.1894], unstable)]
+
+# Maximal Lyapunov exponent — no Jacobian needed
+ts.max_lyapunov(ts.Lorenz(ic=[1, 1, 1]), dt=0.05)        # ≈ 0.9
+```
+
+Plus: **attractors & basins** of any flow or map, correlation/Rényi **fractal
+dimensions**, **permutation/sample/dispersion entropy**, **RQA** (recurrence
+quantification), **surrogate** hypothesis tests, **delay embedding** (Takens,
+optimal τ, Cao/FNN), GALI & the 0–1 chaos test, and Lyapunov exponents **from a
+bare time series** (Kantz/Rosenstein).
+
+## Highlights
+
+- **Three families, one interface**
+
+  - **ODEs**
+
+  - **DDEs**
+  - **SDEs**
+  - **Discrete Maps**
+
+- **151 built-in systems** with literature parameters.
+
+- **Native engine**: equations lower to a Rust engine (an SSA-tape
+  interpreter, with a Cranelift JIT alongside) in-process; parameters are runtime
+  values, so changing them is free and there is no compile step or cache.
+
+- **Composition** — a `PoincareMap` of a flow *is* a discrete map, so
+  `orbit_diagram(PoincareMap(Rossler(), ("y", 0.0)), "c", values)` draws the
+  bifurcation diagram of a *flow* in one line.
+
+- **Backend-neutral plotting** — one `PlotSpec` IR renders to matplotlib, plotly
+  (interactive + animated HTML), three.js, or JSON, with a fluent styling/theming
+  vocabulary.
+
+## Install
+
+```bash
+pip install tsdynamics            # or: uv add tsdynamics
+```
+
+A prebuilt `abi3` wheel (manylinux / musllinux / macOS / Windows) bundles the
+native Rust engine. No Rust toolchain and no C compiler needed to install or
+run. Optional plotting extra: `tsdynamics[plot,interactive]` (matplotlib, plotly).
+
+## Development
+
+```bash
+git clone https://github.com/El3ssar/TSDynamics && cd TSDynamics
+uv sync --group dev --group docs
+uv run pytest -m "not slow" --no-cov     # fast tier
+uv run pytest --no-cov                   # full local suite
+TSD_DOCS_FIGURES=0 uv run mkdocs serve   # docs preview
+```
+
+Releases are automated: conventional-commit PR titles drive
+[semantic-release](https://python-semantic-release.readthedocs.io/) on merge see [CONTRIBUTING](https://el3ssar.github.io/TSDynamics/project/contributing/).
+
+## License
+
+MIT © Daniel Estevez

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-core/src/bridge/marshal.rs

@@ -321,8 +321,11 @@ pub(super) fn guard_continuous(tape: &Tape) -> Result<(), EngineError> {
 
 /// Reject a method that needs an analytic Jacobian when the tape carries none.
 ///
-/// The implicit kernels (`rosenbrock`/`trbdf2`) freeze `∂f/∂u` each step and
-/// solve `(I − c·h·J)`. Driving them over a tape compiled *without* a Jacobian
+/// The guard fires for any kernel whose `caps.needs_jacobian` flag is set — i.e.
+/// the whole implicit family (`rosenbrock`/`trbdf2`/`bdf`/`backward_euler`/
+/// `implicit_midpoint`/`trapezoid`/`sdirk2`), not just the two named below.
+/// These freeze `∂f/∂u` each step and solve `(I − c·h·J)`. Driving them over a
+/// tape compiled *without* a Jacobian
 /// (`with_jacobian=False`) leaves `eval_jac`'s `jac` buffer untouched — i.e. the
 /// all-zeros it was initialised to — so the iteration matrix collapses to `I` and
 /// the L-stable step silently degrades to an *unstable forward-Euler* one: a

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-engine/src/basin.rs

@@ -5,13 +5,21 @@
 //! Python `_AttractorMapper` (stepping + cell-binning + the shared-label early-out)
 //! inside one engine call, so a `basins_of_attraction` image is computed without
 //! the ~10^6–10^7 per-`dt` Python→FFI round-trips and the per-step Python FSM
-//! overhead the released loop pays. It is **bit-identical** to the Python mapper
-//! because it drives the *same* sequential algorithm over the *same* engine
-//! stepper: each cell-check advances a flow by one `dt` (an [`integrate_grid`] over
-//! the two-node grid `[t, t+dt]`, byte-for-byte the per-`dt` integration the Python
-//! `system.step(dt)` runs) or iterates a map once
+//! overhead the released loop pays. It drives the *same* sequential algorithm
+//! over the *same* engine stepper: each cell-check advances a flow by one `dt` (an
+//! [`integrate_grid`] over the two-node grid `[t, t+dt]`, byte-for-byte the
+//! per-`dt` integration the Python `system.step(dt)` runs) or iterates a map once
 //! ([`map_step_once`](crate::map::map_step_once)).
 //!
+//! For **flows** this is **bit-identical** to the Python mapper: both advance the
+//! same engine stepper, so the label image and the located attractor set match
+//! byte-for-byte. For **maps** the Python mapper iterates the pure-Python `_step`
+//! while this kernel runs the lowered IR; the two differ by ULPs, so a
+//! boundary-straddling iterate can bin into a neighbouring cell. In practice the
+//! map label image is still **empirically byte-identical** across the catalogue,
+//! but the guarantee is only *same-attractor* — a chaotic map's located cells may
+//! sit a few cells apart.
+//!
 //! # Layering
 //!
 //! The kernel is agnostic about *which* evaluator (interpreter vs JIT) and *which*

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-engine/src/ensemble.rs

@@ -123,10 +123,14 @@ where
     // Preallocate the contiguous output and write each trajectory DIRECTLY into
     // its own row slice in parallel. Zipping `states.par_chunks_mut(dim)` with
     // `status.par_iter_mut()` partitions the buffers into disjoint, index-aligned
-    // pieces, so worker `i` only ever touches row `i` — no per-trajectory heap
-    // `Vec` and no second copy. The partition is positional, so the output is
-    // still in input order regardless of how rayon schedules the workers
-    // (parallel == serial bit-for-bit, the determinism contract above).
+    // pieces, so worker `i` only ever touches row `i`. The win is avoiding a
+    // GLOBAL collect-then-scatter: there is no intermediate `Vec<Vec<f64>>` of
+    // per-trajectory heap allocations to gather and copy back into the contiguous
+    // buffer. Each trajectory still copies its own final state once — `integrate_final`
+    // returns an owned final-state `Vec`, which is copied into its row. The
+    // partition is positional, so the output is still in input order regardless of
+    // how rayon schedules the workers (parallel == serial bit-for-bit, the
+    // determinism contract above).
     let mut states = vec![0.0; n_ic * dim];
     let mut status = vec![TrajStatus::Ok; n_ic];
     states

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-ir/src/op.rs

@@ -12,10 +12,14 @@
 //! | Kind        | Reads                                   | Ops |
 //! |-------------|-----------------------------------------|-----|
 //! | [`Leaf`]    | an input (`u`/`p`/`t`) or an immediate  | `Const`, `State`, `Param`, `Time` |
-//! | [`Unary`]   | register `a`                            | `Neg`, `Recip`, and the transcendental functions |
-//! | [`Binary`]  | registers `a` **and** `b`               | `Add`, `Sub`, `Mul`, `Div`, `Pow` |
+//! | [`Unary`]   | register `a`                            | `Neg`, `Recip`, the transcendental functions, and the E-OPS unaries `Floor`, `Ceil` |
+//! | [`Binary`]  | registers `a` **and** `b`               | `Add`, `Sub`, `Mul`, `Div`, `Pow`, and the E-OPS binaries: comparisons `Lt`, `Le`, `Gt`, `Ge`, `Eq`, `Ne`, plus `Min`, `Max`, `Mod`, `Rem` |
 //! | [`Powi`]    | register `a`, integer exponent in `b`   | `Powi` |
 //!
+//! (The E-OPS block — the non-smooth / piecewise comparisons, `Min`/`Max`,
+//! `Floor`/`Ceil`, and the floored `Mod` / truncated `Rem` — is the additive
+//! extension of the frozen IR; see the variant list and [`kind()`](Op::kind).)
+//!
 //! For the per-instruction operand layout (which of `a`/`b`/`imm` each kind
 //! reads) see [`crate::Tape`].
 //!

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-solvers/src/explicit/dop853.rs

@@ -11,9 +11,14 @@
 //! it does not use [`adaptive_step`](super::control::adaptive_step): it computes
 //! the 12 stages with the shared machinery, then forms its own blended error
 //! norm `|h|·‖e₅‖² / √((‖e₅‖² + 0.01·‖e₃‖²)·n)` — identical to SciPy's, where
-//! `‖·‖` is the per-component-scaled Euclidean norm.  The 13th (FSAL) stage that
-//! SciPy keeps for dense output has zero weight in both error estimators, so only
-//! the 12 propagation stages are needed here.
+//! `‖·‖` is the per-component-scaled Euclidean norm.
+//!
+//! There is **no propagation FSAL reuse** here: every accepted step recomputes
+//! its 12 propagation stages from scratch (unlike `rk45`/`tsit5`/`bs3`, which
+//! reuse the accepted step's last stage as the next step's first). The 13th
+//! "FSAL" stage that SciPy carries is purely a *dense-output* stage — it has zero
+//! weight in both error estimators and feeds no subsequent propagation step — so
+//! it is not computed here; only the 12 propagation stages are needed.
 
 // The Hairer coefficients are transcribed verbatim from the canonical published
 // set (also SciPy's `dop853_coefficients.py`), at higher precision than f64 can

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-solvers/src/registry.rs

@@ -131,3 +131,61 @@ macro_rules! register_solver {
         }
     };
 }
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    /// Single-source-of-truth guard: every registered kernel's *declared* caps
+    /// (the [`register_solver!`] literal stored in [`SolverRegistration::caps`])
+    /// must equal the caps its freshly-built instance reports from
+    /// [`Solver::caps`](crate::Solver::caps), and likewise for the name.
+    ///
+    /// The two copies are read by *different* engine paths — the Jacobian /
+    /// implicit-kind guards read the registered `reg.caps`
+    /// (`bridge/marshal.rs`, `bridge/dde.rs`, `bridge/sde.rs`), while the
+    /// dense-output / event path reads the instance method `solver.caps()`
+    /// (`tsdyn-engine/src/event.rs`). If a kernel author edited one and not the
+    /// other (e.g. added `.with_dense()` to the registration but not to
+    /// `caps()`), the engine would build a Jacobian-free tape off one capability
+    /// set yet drive event refinement off a *different* one — a silent
+    /// correctness divergence. This test sees every kernel linked into the test
+    /// binary, so any drift fails CI loudly instead.
+    #[test]
+    fn registered_caps_match_instance_caps() {
+        let mut mismatches: Vec<String> = Vec::new();
+        for reg in registered() {
+            let instance = (reg.make)();
+            let inst_caps = instance.caps();
+            let inst_name = instance.name();
+            if inst_caps != reg.caps {
+                mismatches.push(format!(
+                    "{}: registration caps {:?} != instance caps() {:?}",
+                    reg.name, reg.caps, inst_caps
+                ));
+            }
+            if inst_name != reg.name {
+                mismatches.push(format!(
+                    "registration name {:?} != instance name() {:?}",
+                    reg.name, inst_name
+                ));
+            }
+        }
+        assert!(
+            mismatches.is_empty(),
+            "solver registration/instance capability drift:\n{}",
+            mismatches.join("\n")
+        );
+    }
+
+    /// Sanity: the guard above is non-vacuous — there *are* registered kernels
+    /// in the test binary (a dead-stripped registry would make the guard pass
+    /// trivially, see the module-level dead-stripping note).
+    #[test]
+    fn registry_is_non_empty() {
+        assert!(
+            registered().next().is_some(),
+            "no solver kernels registered in the test binary"
+        );
+    }
+}

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/crates/tsdyn-solvers/src/solver.rs

@@ -115,6 +115,15 @@ pub trait Solver: Send {
 
     /// This kernel's [capabilities](Caps): explicit/implicit, adaptive,
     /// Jacobian need, and supported problem families.
+    ///
+    /// **Must equal the caps the kernel declares in its
+    /// [`register_solver!`](crate::register_solver) line**
+    /// ([`SolverRegistration::caps`](crate::SolverRegistration)). The two copies
+    /// are read by different engine paths — the Jacobian / implicit-kind guards
+    /// read the registered copy, while the dense-output / event path reads this
+    /// method — so a drift between them is a silent correctness divergence. The
+    /// `registered_caps_match_instance_caps` registry test asserts they agree
+    /// for every linked kernel, so an out-of-sync edit fails CI.
     fn caps(&self) -> Caps;
 
     /// Advance `st` by one step of size `h`, using `ev` for RHS/Jacobian values.

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "tsdynamics"
-version = "5.2.5"
+version = "5.2.6"
 description = "Zero-warmup Rust-engine ODE/DDE/SDE integration, discrete maps, and chaos analysis for dynamical systems."
 readme = "README.md"
 requires-python = ">=3.12,<4.0"
@@ -152,6 +152,9 @@ ignore = [
   "D101",    # missing docstring in public class — class names are the documentation
   "F841",    # local variable assigned but never used — intentional in _jac methods for visual symmetry
 ]
+# Cross-library benchmark harness (auxiliary, not shipped): adapter classes and
+# their task_* methods are self-documenting by name.
+"benchmarks/**" = ["D101", "D102", "D103"]
 
 [tool.ruff.lint.isort]
 known-first-party = ["tsdynamics"]

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/src/tsdynamics/__init__.py

@@ -363,7 +363,7 @@ bifurcation_diagram = orbit_diagram  #: discoverable spelling of :func:`orbit_di
 basins = basins_of_attraction  #: short alias of :func:`basins_of_attraction`
 
 # Single source of truth for the package version; rewritten by python-semantic-release.
-__version__ = "5.2.5"
+__version__ = "5.2.6"
 
 # Built-in system classes are NOT bound into this namespace — that would bury the
 # submodules (``analysis``, ``data``, ``systems``, …) under ~150 model names in

{tsdynamics-5.2.5 → tsdynamics-5.2.6}/src/tsdynamics/analysis/_result_base.py

@@ -311,6 +311,7 @@ class AnalysisResult:
                 layers=[pb.markers(np.arange(vals.size, dtype=float), vals)],
                 xlabel="field",
                 xticks=list(range(len(names))),
+                xcategories=names,
                 ylabel="value",
                 title=type(self).__name__,
                 meta=self.meta,