Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Update `Recipe` contract to allow for more generic transformations

Open
  • Is something wrong?
#1,071 0 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python, pytorch
Domain
machine-learning

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Python
Stars
316
Forks
27
Avg merge
1d 3h
Merged PRs (30d)
157

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/structured-data-models

All issues in NVIDIA/structured-data-models

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.