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
[numpy] torch.sinh
: promote integer inputs to float
#48644
[numpy] torch.sinh
: promote integer inputs to float
#48644
Conversation
💊 CI failures summary and remediationsAs of commit 9d5971d (more details on the Dr. CI page): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions on the GitHub issue tracker or post in the (internal) Dr. CI Users group. This comment has been revised 29 times. |
test/test_unary_ufuncs.py
Outdated
else: | ||
a = t.cpu().numpy() | ||
# NumPy promotes integer types to double while |
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.
Let's not change test_unary_ufuncs.py to handle this. This logic should live exclusively in the reference function itself.
@@ -408,7 +410,10 @@ def sample_inputs(self, device, dtype, requires_grad=False): | |||
)), | |||
UnaryUfuncInfo('sinh', | |||
ref=np.sinh, |
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.
Just make the reference a function that wraps sinh and promotes integer types to float before calling it. Alternatively it can use NumPy sinh's dtype
kwarg to enforce the computation occurs in the same dtype as in PyTorch. That way the logic can live in the reference.
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.
Rework this so the difference from NumPy is captured entirely in the reference function, and the tests don't need to understand the discrepancy.
I appreciate that in some other cases we've implemented small workarounds for differences with NumPy (mostly around NumPy's inability to handle bfloat16), but this one can be handled more easily by changing the reference, I think.
Ah right. Updated. Thanks! |
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.
Cool! Thanks @kshitij12345.
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.
@mruberry has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@mruberry Thank you for the tweaks and fixes :) |
Codecov Report
@@ Coverage Diff @@
## master #48644 +/- ##
=======================================
Coverage 80.82% 80.82%
=======================================
Files 1863 1863
Lines 200897 200907 +10
=======================================
+ Hits 162371 162380 +9
- Misses 38526 38527 +1 |
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.
@mruberry has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Reference: #42515