Skip to content

[DTensor] Skip all-zero ground truth samples in strategy validator#174535

Closed
wconstab wants to merge 5 commits intogh/wconstab/522/basefrom
gh/wconstab/522/head
Closed

[DTensor] Skip all-zero ground truth samples in strategy validator#174535
wconstab wants to merge 5 commits intogh/wconstab/522/basefrom
gh/wconstab/522/head

Conversation

@wconstab
Copy link
Copy Markdown
Contributor

@wconstab wconstab commented Feb 8, 2026

Stack from ghstack (oldest at bottom):

Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

[ghstack-poisoned]
@pytorch-bot
Copy link
Copy Markdown

pytorch-bot Bot commented Feb 8, 2026

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/174535

Note: Links to docs will display an error until the docs builds have been completed.

⏳ No Failures, 37 Pending

As of commit 894f5c5 with merge base f365425 (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

…alidator"

Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

[ghstack-poisoned]
Copy link
Copy Markdown
Contributor

@pianpwk pianpwk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another common case is all True/False values for boolean tensors.

To be extremely conservative, I'd also consider filtering out cases with all-zeros input tensors, since that can be error prone. Something like scatter_add(input: R, index: S, values: S) -> P could be a false positive, when the input tensor is all zeros

…alidator"

Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

[ghstack-poisoned]
…alidator"

Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

[ghstack-poisoned]
…alidator"

Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

[ghstack-poisoned]
@wconstab
Copy link
Copy Markdown
Contributor Author

squashed

@wconstab wconstab closed this Feb 11, 2026
sandy-gags pushed a commit to sandy-gags/pytorch that referenced this pull request Mar 12, 2026
Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

ghstack-source-id: 5d7d67d
Pull Request resolved: pytorch/pytorch#174535
sandy-gags pushed a commit to sandy-gags/pytorch that referenced this pull request Mar 12, 2026
Moves the all-zero detection from validate_combination to compare_operator.
validate_combination correctly reports that the computation produces matching
results for zero inputs, but the sample is uninformative for distinguishing
valid from invalid rules. Ops like zeros_like, zero_, and new_zeros always
produce zero output, and without this skip every placement combination
trivially validates, generating hundreds of false positive rules.

Authored with Claude.

ghstack-source-id: b52c26b
Pull Request resolved: pytorch/pytorch#174535
@github-actions github-actions Bot deleted the gh/wconstab/522/head branch March 14, 2026 02:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants