Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Update `Recipe` contract to allow for more generic transformations

Aperta
  • Qualcosa non va?
#1,071 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python, pytorch
Ambito
machine-learning

Direzione di ricerca

Start by reading the Recipe, processor lifecycle, and RecipeExecution APIs, then trace how model forward, fit, and predict calls are wired. The issue identifies no files or tests, so locate existing processor and recipe tests before proposing an acceptance test for forecasts at different query positions and clear failure when required coordinates are absent. The coordinate shapes, compatibility contract, and related-table behavior still need design decisions.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

My initial goal was to extend Recipe such that a transformation such as conditional detrending (but not only) could fit there. I'd like to find a way to make it as general and clean as possible.

Proposal for discussion

Recipe can fit a transformation on context rows and invert it on model predictions, but processor calls cannot currently receive the position of each row. A fitted trend therefore cannot be evaluated reliably at future rows, especially when positions have gaps or forecasts are requested out of order.

Here is an illustrative call site. ConditionalLinearDetrend does not exist yet; the goal is a contract that would also support other transformations needing row coordinates.

import torch
import sdm

context_positions = torch.tensor([0., 1., 3., 4.])
query_positions = torch.tensor([6., 9.])
targets = sdm.TableTensor.from_tensor(
    torch.tensor([
        [10., 4.],
        [12., 7.],
        [16., 4.],
        [18., 7.],
    ])
    columns=["load", "alternating"],
)

recipe = sdm.Recipe(
    target=ConditionalLinearDetrend(residual_std_ratio=0.5)
)
recipe.target.fit_transform(
    targets, row_positions=context_positions
)

raw_forecast = sdm.TableTensor.from_tensor(
    torch.tensor([[0., 5.], [0., 6.]]),
    columns=["load", "alternating"],
)
forecast = recipe.target.inverse_transform(
    raw_forecast, row_positions=query_positions
)
assert forecast.numerical.tolist() == [[22., 5.], [28., 6.]]

The load series follows 10 + 2 × position and meets the detrending condition. The alternating series does not, so its predictions remain unchanged. Fitting uses context values only; inversion evaluates the fitted trend at the supplied query positions.

Proposed direction

  • Accept optional row coordinates in the processor lifecycle and pass them through RecipeExecution and model forward, fit, and predict calls.
  • Let processors that need coordinates require them explicitly. Existing processors and recipes should continue to work without them.

Questions to settle

  • What shapes and broadcasting rules should coordinates support for batched tables and ensemble members? Should they represent ordinal steps, arbitrary numeric coordinates, or both?
  • How should a processor declare that coordinates are required while preserving existing processor subclasses?
  • Related tables have their own row axes. How should their coordinates be supplied?
  • Forecasts with several quantiles per target also need an explicit target-to-output mapping for inversion. Should that be a separate issue?

A useful acceptance test would fit once on context, then request forecasts at different query positions in either order. Each result should depend on its supplied positions, while a processor called without required coordinates should fail clearly.

Lingua principale
Python
Stelle
316
Fork
27
Merge medio
1g 3h
PR unite (30g)
157

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NVIDIA/structured-data-models

Tutte le issue di NVIDIA/structured-data-models

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.