Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Update `Recipe` contract to allow for more generic transformations

未关闭
  • 哪里不对？
#1,071 0 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
python, pytorch
领域
machine-learning

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Python
星标
358
派生
33
平均合并
1 天 7 小时
30 天内合并 PR
169

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

NVIDIA/structured-data-models 的其他 Issue

查看 NVIDIA/structured-data-models 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。