Wrap fft for dask

[lithomas1]

There's some failures relating to the expected dtype on older numpy versions.

[asmeurer]

The wrappers in common should already be handling the dtype difference. It looks like the norm keyword isn't working, though.

[lithomas1]

Going to pick this up again this week.

Thanks for not closing.

[lithomas1]

I believe array-api-tests is using a typing feature (|) from Python 3.10, which is causing us to fail here.

Not sure if it's worth patching there, as NEP29 says 3.9 should be dropped anyways.

[asmeurer]

That should be fixed upstream now. Let's keep 3.9 support for now. We should discuss dropping Python support in another issue. I'd prefer to be as conservative as possible with supported Python versions (i.e., not drop support unless we really need to), to maximize compatibility for people.

[lithomas1]

This should be ready for a look now.

Tests are passing with dask main.
(this should be mergeable whenever dask cuts its next release).

[asmeurer]

Does dask still require the wrappers here? The only thing they do for NumPy is fix upcasting for 32-bit types, which has been fixed in NumPy 2.0. If the next version of dask has the NumPy 2.0 behavior then no wrapping is necessary at all.

[lucascolley]

There are errors in SciPy for the device arg of {r}fftfreq. I don't know if array-api-tests has coverage of that, but it should be wrapped here.

EDIT: yes, it looks like CI has caught that here.

[lithomas1]

Ah thanks, I'll go and wrap that.

Curious why it's only on fftfreq and not on fft

[lucascolley]

fftfreq creates an array from scalar inputs, so there is no device to infer.

fft takes arrays as input so can infer the device.

[lithomas1]

I think I was actually wrapping stuff incorrectly all this time
(I forgot to import the wrappers in init)

I'm going to give only wrapping fftfreq/rfftfreq a shot.

[lithomas1]

@asmeurer
This should be ready for a look now.

Sorry for the long delay, had to wrangle with Github Actions/the __all__ tests for a while.

[lucascolley]

nice stuff!

[asmeurer]

There's other similar skips in some of the lines below. We should probably consolidate. I don't know if there's a cleaner way to do it but if you are aware of one let me know!

[asmeurer]

Ideally we would put these sorts of skips in the individual action files for each package, but I don't know if it's possible to do it.

[lithomas1]

I think for now, it might be easier to keep it in here (even though it's less clean), since I don't think any of the other libraries need this Python restriction.

Assuming Python 3.9 gets dropped sometime soonish, it'd probably be easier to remove in this state.

[asmeurer]

We should probably come up with a policy, but I've tried to be very conservative in supporting old versions to make it so this package is as easy for people to adopt as possible. So I don't have immediate plans to drop Python 3.9, although we will obviously want to do so at some point especially as all the wrapped packages stop supporting it.

[asmeurer]

This looks good, and I think the existing tests should be checking all the code that's been added here, so if tests are passing I'm reasonably confident this is all correct.