scipy.fft interface

[peterbell10]

Closes #268

Since the scipy.fft interface matches numpy.fft very closely, this is simple enough to implement. The exception is the n-dimensional hffts which would require more work than the 1d hfft in the numpy interface

[grlee77]

The CI failure here is unrelated (it seems availability of some conda packages for Python 2.7 have changed).

It may be time to just drop Python 2.7 support on master rather than try to fix this, but I will open a separate issue for that.

[grlee77]

Once uarray backend support has been added here, please also revise the following section of the docs:

https://github.com/pyFFTW/pyFFTW/blob/master/docs/source/tutorial.rst#monkey-patching-3rd-party-libraries

[peterbell10]

uarray support is added and works for me locally. I've updated the tutorial as well.

[hgomersall]

What're the uarray changes? I'm a bit out of touch on this...

[peterbell10]

It was just merged into scipy today (scipy/scipy#10383). It means you can provide the implementation for the functions in scipy.fft without monkey-patching. e.g.

import scipy.fft
scipy.fft.fft([1])  # Calls scipy's own implementation

from pyfftw.interfaces import scipy_fft
scipy.fft.set_global_backend(scipy_fft)
scipy.fft.fft([1])  # Calls into pyfftw

See the uarray docs for a description of __ua_function__. It's very similar to NumPy's new __array_function__ protocol if you've heard of that.

[peterbell10]

======================================================================
ERROR: test_scipy_backend (test.test_pyfftw_scipy_fft.InterfacesScipyFFTTestSimple)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/pyFFTW/pyFFTW/test/test_pyfftw_scipy_fft.py", line 99, in test_scipy_backend
    with scipy.fft.set_backend(scipy_fft, only=True):
AttributeError: module 'scipy.fft' has no attribute 'set_backend'

It looks like the scipy dev wheels are built weekly so this test will continue to fail until sometime next week. It passes for me locally though.

[hgomersall]

Does this break without the latest scipy? Is it only this set backend bit?

[peterbell10]

The only issue is that the symbol scipy.fft.set_backend doesn't exist and it's used in the test. I could just skip that test and everything should be fine.

[peterbell10]

And of course if scipy.fft doesn't exist then everything is excluded and skipped already.

[hgomersall]

I think I'd prefer the import code to inspect the scipy version to make it explicit for future reading (scipy.__version__). You could use the same with a SkipIf decorator on the test that's failing, then it should work. Do the dev versions bump the version at the beginning of a development cycle?

[peterbell10]

I think I'd prefer the import code to inspect the scipy version to make it explicit for future reading (scipy.version).

Done

You could use the same with a SkipIf decorator on the test that's failing, then it should work.

Unfortunately the weekly builds are only identified by part of a commit hash so ordered comparison isn't really possible.

Do the dev versions bump the version at the beginning of a development cycle?

Yes, it's currently on 1.4.0.dev0 while the released version is 1.3.0

[hgomersall]

Unfortunately the weekly builds are only identified by part of a commit hash so ordered comparison isn't really possible.

Doesn't the version convey the information? I thought the api changes was 1.3 -> 1.4?

[peterbell10]

Yes, for release versions that will be sufficient but 1.4 hasn't been released yet.

[hgomersall]

Do the comparisons not work on dev releases? I was under the impression the semantic versioning was meant to allow precisely these sort of comparisons...

[peterbell10]

The dev versions are like 1.4.0.dev0+<commit hash> and hashes aren't ordered so comparing hashes with >= doesn't make sense. You can tell that it is a 1.4.0 dev release but you can't tell how far into development it is.

[hgomersall]

Ah I see. Anyway, it looks fine to me. The problem at the moment then is that is breaks against dev releases, but should work find on non-dev versions?

[peterbell10]

Yes, it's only an issue with 1.4.0dev versions from before the uarray features were added. Notice that on travis everything else is passing.

[hgomersall]

Ok, in that case let's wait for the weekly release and then merge.

[hgomersall]

Nice work by the way :)

[larsoner]

@peterbell10 if it makes life easier for this backend work we can probably increment the dev number as 1.4.0dev1

[peterbell10]

Unfortunately LooseVersion isn't smart enough to realise 1.4.0 > 1.4.0.dev0 which would complicate the checking further. I think just waiting until Monday is good enough.

[peterbell10]

The new wheels are out and the tests are now passing.

[grlee77]

This looks good to me with only minor comments to address

[grlee77]

Can you update the numbers here? I am curious if the ratio is currently still similar to that seen here.

[peterbell10]

The gap has closed slightly but I think the main advantage pyfftw has now is multithreading.

[grlee77]

@hgomersall, If these changes look good to you I think we are done here.