Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Update `Recipe` contract to allow for more generic transformations

Đang mở
  • Có gì không ổn?
#1,071 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python, pytorch
Lĩnh vực
machine-learning

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
316
Fork
27
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
157

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của NVIDIA/structured-data-models

Tất cả issue của NVIDIA/structured-data-models

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.