Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Update `Recipe` contract to allow for more generic transformations

Abierto
  • ¿Algo no está bien?
#1,071 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, pytorch
Área
machine-learning

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
316
Forks
27
Merge medio
1 d 3 h
PR fusionados (30 d)
157

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NVIDIA/structured-data-models

Todos los issues de NVIDIA/structured-data-models

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.