-
Notifications
You must be signed in to change notification settings - Fork 633
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure axis masking operations are not in-place #1481
Merged
Merged
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a tricky one. The goal of this test is to ensure that "when mask is randomly applied, the original Tensor is not altered", and in #1478, we learned that bug happens stochastically. So we need to control the randomness in a way that it always hits the condition that caused the issue in #1478.
Simply setting the random seed has a positive and negative effects here. The positive aspect is that the test is repeatable. Assuming that the environment (hardware / software (including everything from OS, PyTorch and CUDA) is the same, we can repeat the test and expect it to produce the same result. But the negative aspect is, we cannot be sure if this specific seed value applies to any configuration (HW/SW) in future? We do not know and it's not likely. If something about the random generator has been changed in the future, and if this seed value stopped hitting the condition, then the test becomes moot.
There are couple of approaches to overcome this.
For example, if we make the test to mask all the elements of the input tensor, we can be sure that the test meets the requirement. However, this diverges from the expected usages (should be masking a part of the input, not all), and looking at the signature/docstring of function tested, it's not straightforward to do so. (It could be, but the docstring is hard to understand.)
If there is no other solution, we can patch the random generator to change the behavior in our favor. This kind of technique is often used in function that relies on external resource (like HTTP access, for example
moto
makes it possible to test your AWS app without internet connection). But this complicates the test logic, which increases the chance of writing a wrong test.Another approach is to bound the probability that the test hits the correct condition. Say that this one attempt will hit the bug condition with probability
p
. If you repeat the proceduren
times, assuming that the implementation of pseudo random generator meets iid, (which I think is a reasonable assumption for this context even though it is not in strict sense) then the probability that the test hits the condition at least once becomes1 - (1 - p)^n
. Forp=0.6
andn=10
, we get something like 99.989 % of hitting the bug condition. The good thing about this approach is that we can still set the seed value once (and only once at the very beginning) and we expect the reproducibility.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with everything here, and feel that option 3 makes the most sense to me. The success in #1478 (when the input tensor is not changed) takes place when
value = torch.rand(1) * mask_param
is equal to0
, which results inmask_start
=mask_end
and no masking takes place. Amask_param
value of 100 in all these tests indicates a 1% probability ofvalue=0
and not hitting the condition. I think therefore looping it over 5 times should be sufficient (> 99.9999%), what do you think? Also, should this reasoning be explained in the documentation or is linking the issue sufficient?Additionally, I have run this test on the previous implementation and see that all these tests fail, indicating that we do hit the condition (although I do agree that the test as is does not ensure this is always true, if we end up changing parameters or if the state of the random seed changes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to know. Thanks for taking the proper care.
Yes, 5 sounds good enough.
Yes, explaining it in the docstring is more helpful for future maintainers. (which is how I learned this kind of technique in the past)