fix: LagsAdder.features_added() over-reports lags outside the horizon window#1023
Open
Valyrian-Code wants to merge 1 commit into
Open
fix: LagsAdder.features_added() over-reports lags outside the horizon window#1023Valyrian-Code wants to merge 1 commit into
Valyrian-Code wants to merge 1 commit into
Conversation
… window ## What LagsAdder.transform() only materializes lags that fall within a horizon's valid window (>= the horizon and <= history_available); a configured lag below the shortest horizon or beyond history_available is never added. But features_added() returned a name for every configured lag, so it advertised columns that transform() never creates -- a contract mismatch that can mislead any consumer relying on it (feature selection / column validation). ## Fix Return only the lags transform() actually produces: the union of the per-horizon valid lags (self._horizon_lags), matching the columns built in _transform_single_horizon / _transform_versioned. Same shape of fix as the merged OpenSTEF#965 (RollingAggregatesAdder) and OpenSTEF#980 (DatetimeFeaturesAdder). ## Tests Added regression tests (fail on the previous code, pass with the fix): single-horizon and multi-horizon cases assert features_added() equals the columns transform() actually adds, with out-of-window custom_lags dropped. ruff, format, ty clean; models transforms (64) and meta presets (29) pass. Signed-off-by: RAJVEER42 <irajveer.bishnoi2310@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
LagsAdder.transform()only materializes lags that fall within a horizon's valid window (>=the horizon and<=history_available) — a configured lag below the shortest horizon, or beyond the available history, is never added. Butfeatures_added()returned a name for every configured lag (self._lags), so it advertised columns thattransform()never creates.That is a contract mismatch: any consumer relying on
features_added()(feature selection, column validation) is told about columns that never materialize. Same defect shape as the recently merged #965 (RollingAggregatesAdder) and #980 (DatetimeFeaturesAdder).Concretely, with
history_available=10d,horizons=[2D],custom_lags=[1D, 3D, 30D],add_trivial_lags=False:transform()adds onlyload_lag_P3D(1D is below the 2D horizon, 30D exceeds the 10D history);features_added()previously returnedload_lag_P30D,load_lag_P3D,load_lag_P1D.Fix
Return only the lags
transform()actually produces — the union of the per-horizon valid lags (self._horizon_lags), which mirrors the columns built in_transform_single_horizon/_transform_versioned:No change to
transform(), thelags/horizon_lagsproperties, or any public field.Tests
Added regression tests (both fail on the previous code, pass with the fix):
features_added()equals the columnstransform()adds, with the out-of-windowcustom_lagsdropped;features_added()equals the union of columns created across horizons.ruff check,ruff format --check, andty checkare clean on the changed files. Theopenstef-modelstime-domain transforms suite (64) and theopenstef-metapresets suite (29 — the one internal consumer,forecasting_workflow.py, uses this as an exclude set where the change is behaviour-preserving) both pass.