Skip to content

Enable fixed fast_mode for complex #55699

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

Closed
wants to merge 19 commits into from

Conversation

soulitzer
Copy link
Contributor

@soulitzer soulitzer commented Apr 9, 2021

Stack from ghstack:

Todo:

  • error message should be updated to say whether the failure is for fn's real or imaginary component

Differential Revision: D28007887

@facebook-github-bot
Copy link
Contributor

facebook-github-bot commented Apr 9, 2021

💊 CI failures summary and remediations

As of commit 04831f0 (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 to the (internal) Dr. CI Users group.

soulitzer added a commit that referenced this pull request Apr 9, 2021
ghstack-source-id: 679f608
Pull Request resolved: #55699
soulitzer added a commit that referenced this pull request Apr 12, 2021
ghstack-source-id: 52e5995
Pull Request resolved: #55699
@soulitzer soulitzer mentioned this pull request Apr 16, 2021
Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component


[ghstack-poisoned]
Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component


[ghstack-poisoned]
Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component


[ghstack-poisoned]
Copy link
Collaborator

@albanD albanD left a comment

Choose a reason for hiding this comment

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

The logic looks ok for me.

I wonder if there would be a way to have u as an object so that you don't need to add a new argument to every function.
That object would contain one or two real valued vectors.
And you unpack it properly depending if you're considering complex or not when you need it. What do you think?

@@ -201,7 +201,7 @@ def compute_numerical_jacobian_cols(jvp_fn, delta, input_is_complex) -> List[tor
ds_dx_tup = jvp_fn(delta)

if input_is_complex: # C -> R
ds_dy_tup = jvp_fn(delta * 1j)
ds_dy_tup = jvp_fn(delta * 1j) if delta_i is None else jvp_fn(delta_i * 1j)
Copy link
Collaborator

Choose a reason for hiding this comment

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

If the input is complex, delta_i should never be None right?
Or the slow version uses same delta for both?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Slow version does not use delta_i. But now I've changed it to use a single parameter delta object which may be either tuple or tensor or python number. It will be always python number in the slow case, and tuple or tensor in the fast case depending on whether that input is complex.

@soulitzer
Copy link
Contributor Author

soulitzer commented Apr 26, 2021

Having a single object u instead of having to pass ui, ur as separate arguments does seem to simply the code a bit, especially once you consider adding more logic to only generate ui if the particular input is complex. Good idea!

Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component


[ghstack-poisoned]
Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component


[ghstack-poisoned]
@soulitzer soulitzer requested a review from albanD April 26, 2021 01:59
Copy link
Collaborator

@albanD albanD left a comment

Choose a reason for hiding this comment

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

LGTM
Just a couple comments to update and it is good!

else:
if u.layout != torch.sparse_coo:
return u.reshape(shape)
return u
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: add a comment here saying that we don't need to reshape for sparse Tensors.

@@ -815,6 +843,7 @@ def adjusted_atol(atol, u, v):
#
# We see that atol needs to be scaled by v^T M u (where M is an all-ones M x N matrix):
# v^T M u = \sum_{i} \sum_{j} u_i * v_j = (\sum_{i} u_i)(\sum_{i} v_i)
u = u[0] if isinstance(u, tuple) else u
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe a comment explaining why we ignore the second part of u? Or a todo if that needs to be done later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah still need to think about how to handle the complex case here. I've moved the other TODO you mentioned to here.

Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component


[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

@soulitzer merged this pull request in 201ad93.

@facebook-github-bot facebook-github-bot deleted the gh/soulitzer/11/head branch May 1, 2021 14:16
crcrpar pushed a commit to crcrpar/pytorch that referenced this pull request May 7, 2021
Summary:
Pull Request resolved: pytorch#55699

Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component

Test Plan: Imported from OSS

Reviewed By: H-Huang

Differential Revision: D28007887

Pulled By: soulitzer

fbshipit-source-id: 1819201f59c8586a1d9631db05983969438bde66
krshrimali pushed a commit to krshrimali/pytorch that referenced this pull request May 19, 2021
Summary:
Pull Request resolved: pytorch#55699

Todo:
- error message should be updated to say whether the failure is for fn's real or imaginary component

Test Plan: Imported from OSS

Reviewed By: H-Huang

Differential Revision: D28007887

Pulled By: soulitzer

fbshipit-source-id: 1819201f59c8586a1d9631db05983969438bde66
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants