Bug fix: allow std 0 in the meta definition of normal_#69631
Bug fix: allow std 0 in the meta definition of normal_#69631nkaretnikov wants to merge 1 commit intogh/nkaretnikov/4/basefrom
Conversation
All other normal variants allow 0. Looks like a mistake made while
copying the check. Even the normal_ implementation disagrees:
>>> t = torch.rand(2, 3, device='meta')
>>> t.normal_(mean=4, std=0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: normal_ expects std > 0.0, but found std=0
>>>
>>>
>>> t = torch.rand(2, 3)
>>> t.normal_(mean=4, std=0)
tensor([[4., 4., 4.],
[4., 4., 4.]])
Fixes #69523.
[ghstack-poisoned]
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit e76cb4a (more details on the Dr. CI page):
🕵️ 13 new failures recognized by patternsThe following CI failures do not appear to be due to upstream breakages:
|
CI Flow Status⚛️ CI FlowRuleset - Version:
You can add a comment to the PR and tag @pytorchbot with the following commands: # ciflow rerun, "ciflow/default" will always be added automatically
@pytorchbot ciflow rerun
# ciflow rerun with additional labels "-l <ciflow/label_name>", which is equivalent to adding these labels manually and trigger the rerun
@pytorchbot ciflow rerun -l ciflow/scheduled -l ciflow/slowFor more information, please take a look at the CI Flow Wiki. |
lezcano
left a comment
There was a problem hiding this comment.
Makes sense!
Could you please add a test that tests this behaviour for all the normal variants? Whenever std is zero (or all zeros), torch.normal should return a vector of the correct size with the inputs of mean.
@lezcano i can, but shouldn't it be done when the normal opfino lands? or is it okay to have tests without opinfos? (i haven't looked much into it.) |
|
to avoid confusion, will open a new stack to address issues related to BC and broadcasting |
Stack from ghstack:
All other normal variants allow 0. Looks like a mistake made while
copying the check. Even the normal_ implementation disagrees:
Fixes #69523.