Skip to content
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

Closed
wants to merge 7 commits into from
Closed

Log1p for complex in CPU #89691

wants to merge 7 commits into from

Conversation

mfkasim1
Copy link
Contributor

@mfkasim1 mfkasim1 commented Nov 25, 2022

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

@pytorch-bot
Copy link

pytorch-bot bot commented Nov 25, 2022

🔗 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 Failures

As of commit 3f03070:

The following jobs have failed:

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

@github-actions github-actions bot added the module: cpu CPU specific problem (e.g., perf, algorithm) label Nov 25, 2022
Comment on lines +1101 to +1106
(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),
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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

Copy link
Collaborator

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.

@albanD albanD added the triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module label Nov 29, 2022
@mfkasim1 mfkasim1 requested review from jgong5 and kit1980 and removed request for ngimel, mruberry, jgong5 and kit1980 November 30, 2022 13:30
Copy link
Collaborator

@lezcano lezcano left a 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):
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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!

Comment on lines +1101 to +1106
(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),
Copy link
Collaborator

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.

Copy link
Collaborator

@jgong5 jgong5 left a comment

Choose a reason for hiding this comment

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

LGTM

@mfkasim1
Copy link
Contributor Author

mfkasim1 commented Dec 5, 2022

What’s the next step for this?

@lezcano
Copy link
Collaborator

lezcano commented Dec 5, 2022

We should add tests for the vectorised paths. Once that's done we can merge this.

Copy link
Collaborator

@lezcano lezcano left a comment

Choose a reason for hiding this comment

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

Great, thank you!

@lezcano
Copy link
Collaborator

lezcano commented Dec 5, 2022

@pytorchbot merge

@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Dec 5, 2022
@pytorchmergebot
Copy link
Collaborator

Merge started

Your 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

Advanced Debugging
Check the merge workflow status
here

@pytorchmergebot
Copy link
Collaborator

Merge failed

Reason: The following mandatory check(s) failed (Rule Core Reviewers):

Dig deeper by viewing the failures on hud

Details for Dev Infra team Raised by workflow job

@lezcano
Copy link
Collaborator

lezcano commented Dec 6, 2022

@pytorchbot merge -f "unrelated error"

@pytorchmergebot
Copy link
Collaborator

Merge started

Your 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

Advanced Debugging
Check the merge workflow status
here

@mfkasim1
Copy link
Contributor Author

mfkasim1 commented Dec 7, 2022

Thanks @lezcano, @jgong5, @kit1980, @mruberry for your help!

kulinseth pushed a commit to kulinseth/pytorch that referenced this pull request Dec 10, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ciflow/trunk Trigger trunk jobs on your pull request Merged module: cpu CPU specific problem (e.g., perf, algorithm) open source triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants