-
Notifications
You must be signed in to change notification settings - Fork 50
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
Conversation
"trimmed to length n" also isn't very clear. Does this mean it should take the first |
Also cleanup some wording for consistency. This fixes the incorrect output shape for ihfft. Fixes data-apis#718.
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. |
Closes: data-apis#667 PR-URL: data-apis#713
PR-URL: data-apis#723 Reviewed-by: Athan Reines <[email protected]>
Okay, this took a bit of digging, but I believe that @leofang is largely correct. The current state of the "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., Clearly that is not the case if So far the spec - let's update the wording to reflect that. For implementations:
|
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.
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. |
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. |
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
These changes all LGTM. I think if they are backported and added to the Changelog, this is good to merge. |
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! |
Also extend the description of errors when DLPack cannot be supported
I've backported everything to 2022.12. I've left out the changelog based on #720 (comment). |
src/array_api_stubs/_2022_12/fft.py
Outdated
- ``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``. |
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.
@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?
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.
Let's address this in a small follow-on PR.
@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? |
Interesting, I thought only Gitlab would be confused not GitHub 😀 We squash-merged, right? |
Yes, we did. 😀 |
Thanks for all the editing, Aaron/Athan. Looks nice! I sent a tiny follow-up: #743 |
PR-URL: #743 Reviewed-by: Athan Reines <[email protected]> Ref: #720
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 tofftfreq
andrfftfreq
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