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

Fix nan gradient by using native complex abs op #1013

Merged
merged 1 commit into from
Jan 6, 2021

Conversation

mthrok
Copy link
Collaborator

@mthrok mthrok commented Nov 6, 2020

Resolves #993

n_fft=2048,
hop_length=None,
win_length=None,
power=1,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@anjali411 Should I also ensure this when power is other than 1?

@mthrok mthrok marked this pull request as ready for review November 6, 2020 16:45
@mthrok mthrok force-pushed the fix-spectrogram-backward branch 2 times, most recently from 54df934 to defc8b7 Compare November 6, 2020 23:30
Comment on lines 112 to 95
if power == 1.0:
return spec_f.abs()
if power == 2.0 and spec_f.is_cuda:
return torch.view_as_real(spec_f).pow(power).sum(-1)
return spec_f.abs().pow(power)
return torch.view_as_real(spec_f)
Copy link
Contributor

@vincentqb vincentqb Nov 10, 2020

Choose a reason for hiding this comment

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

This logic could be moved to complex_norm directly, no? This would benefit other locations.

Choose a reason for hiding this comment

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

yeah I agree we should move this logic to complex_norm

Comment on lines 114 to 115
if power == 2.0 and spec_f.is_cuda:
return torch.view_as_real(spec_f).pow(power).sum(-1)
Copy link
Contributor

@vincentqb vincentqb Nov 10, 2020

Choose a reason for hiding this comment

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

Can you explain why power == 2.0 and spec_f.is_cuda must be treated differently from the generic case on line 116 below?

Copy link
Contributor

@vincentqb vincentqb Nov 10, 2020

Choose a reason for hiding this comment

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

I'm assuming this is the reason. It's not clear the gain is significant. If this is indeed to go in, I would add a comment here.

Copy link
Contributor

@vincentqb vincentqb left a comment

Choose a reason for hiding this comment

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

LGTM, but I would move the logic to compute the complex norm out of spectrogram, and move to the complex_norm functional. This would potentially benefit other locations, and keep the semantic cleaner.

@mthrok mthrok force-pushed the fix-spectrogram-backward branch from defc8b7 to ed798ad Compare January 6, 2021 15:34
@mthrok mthrok merged commit a7797d5 into pytorch:master Jan 6, 2021
@mthrok mthrok deleted the fix-spectrogram-backward branch January 6, 2021 16:13
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.

torchaudio.transforms.Spectrogram with power=1 can easily NaN
5 participants