Description
`StepPredictor.forward`'s docstring (neural_lam/models/step_predictors/base.py) summarizes the call as:
```
Advance the state by one step:
(X_{t-1}, X_t, forcing_t) -> X_{t+1}.
```
But the actual signature is `forward(self, prev_state, prev_prev_state, forcing)`, and the per-parameter docs immediately below correctly state `prev_state` is the current state `X_t` and `prev_prev_state` is the previous state `X_{t-1}`. So the one-line summary formula has the first two arguments backwards relative to both the signature and its own parameter docs.
No runtime bug - all call sites (e.g. `ARForecaster`) already call it in the correct `(X_t, X_{t-1}, forcing)` order matching the signature - this is purely a misleading docstring that could trip up anyone calling a `StepPredictor` positionally based on the summary line.
Fix
Swap the order in the summary line to `(X_t, X_{t-1}, forcing_t) -> X_{t+1}`.
Description
`StepPredictor.forward`'s docstring (neural_lam/models/step_predictors/base.py) summarizes the call as:
```
Advance the state by one step:
(X_{t-1}, X_t, forcing_t) -> X_{t+1}.
```
But the actual signature is `forward(self, prev_state, prev_prev_state, forcing)`, and the per-parameter docs immediately below correctly state `prev_state` is the current state `X_t` and `prev_prev_state` is the previous state `X_{t-1}`. So the one-line summary formula has the first two arguments backwards relative to both the signature and its own parameter docs.
No runtime bug - all call sites (e.g. `ARForecaster`) already call it in the correct `(X_t, X_{t-1}, forcing)` order matching the signature - this is purely a misleading docstring that could trip up anyone calling a `StepPredictor` positionally based on the summary line.
Fix
Swap the order in the summary line to `(X_t, X_{t-1}, forcing_t) -> X_{t+1}`.