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

Clean up some wording in the fft extension #720

Merged
merged 45 commits into from Feb 8, 2024
Merged

Conversation

asmeurer
Copy link
Member

@asmeurer asmeurer commented Dec 12, 2023

Fixes #717.

I also plan to fix #718 here.

Note: this should also be backported, but I want to make sure the wording here looks good first before I do that.

Also, I haven't done it here, but we should consider whether we want to add a dtype argument to fftfreq and rfftfreq for consistency with the other creation functions. Right now, they return the default real floating-point dtype, but there's no way to change that. However, note that np.fft does not implement a dtype argument for these functions.

Ref: #189

@asmeurer
Copy link
Member Author

"trimmed to length n" also isn't very clear. Does this mean it should take the first n elements?

Also cleanup some wording for consistency.

This fixes the incorrect output shape for ihfft.

Fixes data-apis#718.
@asmeurer
Copy link
Member Author

I've also pushed an update to specify output lengths. Please check carefully.

I've also tried to clean up the wording a bit. However, I'm not sure if my wording here is always consistent with wording elsewhere in the spec, so let me know if something should be changed.

I noticed that we aren't consistent throughout the spec with "length" vs. "size" to refer to the size of an axis.

src/array_api_stubs/_draft/fft.py Outdated Show resolved Hide resolved
@rgommers
Copy link
Member

rgommers commented Jan 9, 2024

Okay, this took a bit of digging, but I believe that @leofang is largely correct. The current state of the fft docs is inconsistent, and has been in that state since the initial merge of gh-189. The problem is that the Parameters section says that the first input x must have a "floating-point dtype" (so may be real), while the prominent note right above it says:

"Applying the one-dimensional inverse discrete Fourier transform to the output of this function must return the original (i.e., non-transformed) input array within numerical accuracy (i.e., ifft(fft(x)) == x), provided that the transform and inverse transform are performed with the same arguments (length, axis, and normalization mode)."

Clearly that is not the case if x would be real, because the roundtripping changes the dtype from real to complex (e.g., float64 to complex128). Hence real input should be rejected.

So far the spec - let's update the wording to reflect that. For implementations:

  • The reference implementation should raise on non-complex input dtypes to fft/fftn.
  • For NumPy 2.0, that'd be one bridge too far I think, so let's open an issue first - there are more issues with numpy.fft that need addressing. Accepting non-complex input and treating it like complex with a zero imaginary component will simply be one oddity that perhaps can be addressed over time.

@asmeurer
Copy link
Member Author

Would we want to backport this to 2022.12, or just add it to the draft?

See the discussion at data-apis#720

This still requires changelog entries.
@asmeurer
Copy link
Member Author

I've pushed a change that updates these functions to only require complex-valued inputs. I think this will also require a changelog entry, but I didn't add it yet because I don't know if it will be part of 2023.12 only or backported.

This PR also requires some review for other the wording changes that have been made, as discussed above.

@kgryte
Copy link
Contributor

kgryte commented Jan 10, 2024

IMO, I think it is a bug in the 2022.12 revision and should be backported. For the changelog entry, we can add that in a subsequent PR along with the other specification changes which should be documented similarly.

@rgommers rgommers added Maintenance Bug fix, typo fix, or general maintenance. topic: FFT Fast Fourier transforms. labels Jan 11, 2024
The problem was that the sidebar doesn't show the named pages in the
toctree if that toctree is under a subheading in index.rst

Closes data-apisgh-716
@rgommers
Copy link
Member

These changes all LGTM. I think if they are backported and added to the Changelog, this is good to merge.

@leofang leofang self-requested a review January 12, 2024 00:50
@leofang
Copy link
Contributor

leofang commented Jan 12, 2024

Sorry I dropped the ball here. I think the PR looks good now from a quick glance. I can do a more thorough look tomorrow, but don't let me stop the progress 🙂 Thanks Aaron and all for the improvement!

@leofang leofang added this to the v2023 milestone Jan 12, 2024
@asmeurer
Copy link
Member Author

I've backported everything to 2022.12. I've left out the changelog based on #720 (comment).

@kgryte
Copy link
Contributor

kgryte commented Feb 8, 2024

@leofang Looking at the CI logs, looks like you need to locally install dev deps in order to run the pre-commit hook which will apply black formatting before pushing.

- ``n`` is less than the length of the input array, the input array is trimmed to length ``n``.
- ``n`` is not provided, the length of the transformed axis of the output must equal the length of the input along the axis specified by ``axis``.
- ``n`` is greater than the length of the input array along ``axis``, the input array along ``axis`` must be zero-padded to length ``n``.
- ``n`` is less than the length of the input array along ``axis``, the input array along ``axis`` must be trimmed to length ``n``.
Copy link
Contributor

@kgryte kgryte Feb 8, 2024

Choose a reason for hiding this comment

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

@leofang Sorry for my ignorance, but "trimmed" in this case means the last N-n elements are removed? Or equivalently, only use the first n elements when computing the transform?

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's address this in a small follow-on PR.

@kgryte
Copy link
Contributor

kgryte commented Feb 8, 2024

I think we are good to go ahead and merge this in. Any additional tweaks can be addressed in follow-on PRs.

Thanks, @asmeurer and @leofang!

@kgryte kgryte merged commit 937d3b8 into data-apis:main Feb 8, 2024
3 checks passed
@leofang
Copy link
Contributor

leofang commented Feb 8, 2024

@kgryte thanks, I'll check again later today. One thing I noticed: the diff contains a lot of non-FFT-related changes, is this expected?

@kgryte
Copy link
Contributor

kgryte commented Feb 8, 2024

@leofang GitHub seems confused. The actual diff only includes FFT changes. See 937d3b8.

@leofang
Copy link
Contributor

leofang commented Feb 8, 2024

Interesting, I thought only Gitlab would be confused not GitHub 😀 We squash-merged, right?

@kgryte
Copy link
Contributor

kgryte commented Feb 8, 2024

We squash-merged, right?

Yes, we did. 😀

@leofang
Copy link
Contributor

leofang commented Feb 8, 2024

Thanks for all the editing, Aaron/Athan. Looks nice! I sent a tiny follow-up: #743

kgryte pushed a commit that referenced this pull request Feb 8, 2024
PR-URL: 	#743
Reviewed-by: Athan Reines <kgryte@gmail.com>
Ref: #720
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Maintenance Bug fix, typo fix, or general maintenance. topic: FFT Fast Fourier transforms.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RFC: add support for a dtype kwarg to fftfreq and rfftfreq Specify output shapes for fft functions
7 participants