-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Log1p for complex in CPU #89691
Log1p for complex in CPU #89691
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/89691
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 FailuresAs of commit 3f03070: This comment was automatically generated by Dr. CI and updates every 15 minutes. |
(0.2 + 0.3j, 0.21263386770217202 + 0.24497866312686414j), | ||
(1e-19 + 1e-18j, 1e-19 + 1e-18j), | ||
(1e-18 + 0.1j, 0.00497517 + 0.0996687j), | ||
(0.1 + 1e-18j, 0.0953102 + 9.090909090909090909e-19j), | ||
(0.5 + 0j, 0.40546510810816 + 0j), | ||
(0.0 + 0.5j, 0.111571776 + 0.463647609j), |
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.
Consider using numpy as a ref check instead hard-coding the ref result?
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.
numpy's log1p
suffers from loss of precision with relatively small complex number (see here). That's why I'm using the hard-coded results, calculated from arbitrary-precision math and wolfram alpha.
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.
@mfkasim1 please mention that in the code comment, otherwise someone may try to replace the hardcoded values 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.
Writing a test like this is so unusual now that, as @kit1980 mentions, it absolutely needs a comment. In the future we may want to extend the test framework to automatically generate "golden value" tests.
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.
Done adding comments on the test
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.
We do have golden testing in some parts of PyTorch. I wonder how difficult would it be to use it here... Probably too much to be worth the effort really, but yeah.
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.
Left a couple comments on the testing, but otherwise it looks good.
For the complex part, you can see how it's done for cuda/UnaryLogKernels.cu. You may want to do this in a follow-up PR.
@@ -1094,6 +1094,48 @@ def test_mish(self, device, dtype): | |||
rtol=rtol, | |||
) | |||
|
|||
@dtypes(torch.complex64, torch.complex128) | |||
@onlyCPU | |||
def test_log1p_complex(self, device, dtype): |
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.
Given that you added vectorisation paths for this fucntion, it'd be good to also test those. In particular, I think that running it on tensors of size 8 should already do the trick.
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.
Actually, this may something that may be of interest in general for unary and binary ufuncs. See test_unary_ufuncs.py
. Perhaps someone from intel may be interested in implementing this? @jgong5 The reference for the test can be either numpy or a non-contiguous tensor.
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.
Actually, this may something that may be of interest in general for unary and binary ufuncs. See
test_unary_ufuncs.py
. Perhaps someone from intel may be interested in implementing this? @jgong5 The reference for the test can be either numpy or a non-contiguous tensor.
You are talking about a way of test the vector and non-vector implementation in general, right? I noticed that a lot of tests in test_unary_ufuncs.py
already use a big size and should hit the vector path already (even though the scalar path might not be covered then). Some tests use smaller size and the vector path is not covered though. This would need a more thorough review to know the current status. We can probably make sure all the implementations can trigger the vector path and then control the ATEN_CPU_CAPABILITY
env var to cover both vector and non-vector paths with the same test code. cc @sanchitintel and @mingfeima for their opinions.
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.
So, what I've seen is that there are some one-offs tests for some ops, but we could potentially have a dedicated test that tests the vectorised path against the non-vectorised explicitly. The plan to test depending on the CPU capabilities sounds great as well!
(0.2 + 0.3j, 0.21263386770217202 + 0.24497866312686414j), | ||
(1e-19 + 1e-18j, 1e-19 + 1e-18j), | ||
(1e-18 + 0.1j, 0.00497517 + 0.0996687j), | ||
(0.1 + 1e-18j, 0.0953102 + 9.090909090909090909e-19j), | ||
(0.5 + 0j, 0.40546510810816 + 0j), | ||
(0.0 + 0.5j, 0.111571776 + 0.463647609j), |
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.
We do have golden testing in some parts of PyTorch. I wonder how difficult would it be to use it here... Probably too much to be worth the effort really, but yeah.
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.
LGTM
What’s the next step for this? |
We should add tests for the vectorised paths. Once that's done we can merge this. |
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.
Great, thank you!
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Merge failedReason: The following mandatory check(s) failed (Rule Dig deeper by viewing the failures on hud Details for Dev Infra teamRaised by workflow job |
@pytorchbot merge -f "unrelated error" |
Merge startedYour change will be merged immediately since you used the force (-f) flag, bypassing any CI checks (ETA: 1-5 minutes). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Another PR for pytorch#89205: making torch.log1p accepts complex numbers in CPU. I haven't done the GPU version because I'm not sure which file(s) to change. Pull Request resolved: pytorch#89691 Approved by: https://github.com/jgong5, https://github.com/lezcano
Another PR for #89205: making torch.log1p accepts complex numbers in CPU.
I haven't done the GPU version because I'm not sure which file(s) to change.
cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10