v0.13.1

This release adds Python 3.11 support and drops Python 3.7 support.

Additionally we now generate wheels for more setups including Pypy 3.8 for some architectures in addition to Windows 32-bit and Windows ARM 64-bit.

What's Changed

• fix typo by @MicaelJarniac in #345
• Additional platform support and removal of support for old setups by @JeppeKlitgaard in #351

New Contributors

• @MicaelJarniac made their first contribution in #345

Full Changelog: v0.13.0...v0.13.1

v0.13.0

pyFFTW v0.13.0 release notes

We're happy to announce the release of pyFFTW v0.13.0!

pyFFTW is a pythonic wrapper around FFTW 3, the speedy FFT library. The
ultimate aim is to present a unified interface for all the possible transforms
that FFTW can perform.

pyFFTW implements the NumPy and SciPy FFT interfaces in order for users to take
advantage of the speed of FFTW with minimal code modifications. A Dask FFT
interface is provided as a drop-in replacement for the equivalent module in
dask. For more information, examples, and documentation, please see
the documentation <https://pyfftw.readthedocs.io/en/latest/>_.

A highlight of this release is the addition of real-to-real transforms,
specifically the type I-IV discrete sine and cosine transforms. These
transforms are also available from the pyfftw.interfaces.numpy_fft and
pyfftw.interfaces.scipy_fft interfaces as well as the legacy
pyfftw.interfaces.scipy_fftpack interface.

The NumPy interfaces have also now been updated to support new normalization
options added in NumPy 1.20. The new 'backward' and 'forward' options are
described in the NumPy docs <https://numpy.org/doc/1.20/reference/routines.fft.html#normalization>_.

This release supports Python 3.7-3.10 on Windows, MacOS and Linux. For more
details on the architectures providing binary wheels on PyPI, see the
full table of prebuilt wheels <https://github.com/pyFFTW/pyFFTW#wheels>.
Binary packages for new Apple M1 processors will be made available via
conda-forge <https://conda-forge.org/>.

Pull requests for v0.13.0

---

• add pyproject.toml (#226)
• Real-to-real transforms (#256)
• Drop testing on Python 2.7 and 3.5 (#285)
• Minor doc changes to README (#305)
• Document PYFFTW_INCLUDE and PYFFTW_LIB_DIR (#311)
• Build wheels on GitHub Actions via cibuildwheel (#318)
• Fixed setup.py and working CI builds (#323)
• Update NumPy and SciPy interfaces with new norm options (take 2) (#330)
• CI: Added the correct gh actions badge and tweaked the name of the workflow (#331)
• CI: Improved badge to link to the actual workflow (#332)
• remove use of distutils (#333)
• Increase time allowed for cache clearance in test (#334)
• Increase timing in cache tests (#336)
• Fix miscellaneous typos (#337)

8 authors added to this release [alphabetical by first name or login]

• Chris Val
• David Wells
• Gregory Lee
• Henry Gomersall
• Jeppe Klitgaard
• Jonathan Essen
• Pierre Augier
• Tim Gates

3 reviewers added to this release [alphabetical by first name or login]

• Gregory Lee
• Henry Gomersall
• Jeppe Klitgaard

Version 0.12.0 Release

Release Notes

We are happy to announce the release of pyFFTW v0.12.0.

The highlight of this release is the addition of interfaces for the scipy.fft module that was introduced with SciPy 1.4. This release is now compatibile with SciPy 1.4. This release supports Python 2.7 and 3.5 - 3.8. It is the last release that will have Python 2 support.

pyFFTW is a pythonic wrapper around FFTW 3, the speedy FFT library. The ultimate aim is to present a unified interface for all the possible transforms that FFTW can perform.

Both the complex DFT and the real DFT are supported, as well as on arbitrary axes of abitrary shaped and strided arrays. Operating FFTW in multithreaded mode is supported.

pyFFTW implements the numpy and scipy fft interfaces in order for users to take advantage of the speed of FFTW with minimal code modifications. A dask fft interface is provided as a drop-in replacement for the equivalent module in dask.

New features

scipy.fft interface

This interface operates like the existing scipy.fftpack interface, but
matches the API of the newer scipy.fft module introduced in SciPy 1.4.

Bugs Fixed

The test suite was updated to be compatible with more recent dask (#278).

The Cython variable _N was renamed to avoid a name conflict with a preprocessor token on some platforms (#259).

Other changes

Python 3.4 support has been dropped. pyFFTW now supports Python 2.7 and 3.5-3.8.

The Cython code has been updated to explicitly use language_level=3str for compatibility with a future Cython 3.0 release.

Authors

• Peter Bell +
• Gregory R. Lee
• Stefan Peterson +
• DWesl +

A total of 4 people contributed PRs to this release.
People with a "+" by their names contributed a patch for the first time.

John Kirkham and Henry Gomersall also contributed by helping review PRs.

Version 0.11.1 Release

This is release hash no changes in features or bug fixes to user-facing code. It involved only a couple of minor tweaks to setup.py and the CI scripts needed to improve packaging/wheel building for the release.

Version 0.11.0 Release

pyFFTW v0.11.0 Release Notes

We are happy to announce the release of pyFFTW v0.11.0. This release is the result of more than two years of work by 9 contributors.

pyFFTW is a pythonic wrapper around FFTW 3, the speedy FFT library. The ultimate aim is to present a unified interface for all the possible transforms that FFTW can perform.

Both the complex DFT and the real DFT are supported, as well as on arbitrary axes of abitrary shaped and strided arrays. Operating FFTW in multithreaded mode is supported.

pyFFTW implements the numpy and scipy fft interfaces in order for users to take advantage of the speed of FFTW with minimal code modifications. A dask fft interface is provided as a drop-in replacement for the equivalent module in dask.

New features

Dask interface

A complete drop-in replacement of Dask Array's FFT module is provided.
It includes all numpy-like FFT functions, which use FFTW under the hood.
Other functions from Dask Array's FFT module are imported as a convenience.

Fast transform planning utility

A routine next_fast_len has been added to allow the user to easily determine sizes for which the FFT computation is computationally efficient.

Expanded support for norm keyword argument in the numpy interfaces

Support for the norm keyword argument has been expanded to all numpy FFT interfaces. It was previously present only for the complex-valued routines.

Support for norm keyword argument in FFTW builders

A norm keyword argument has been added to the FFTW builders allowing the normalization of pre-planned FFTs to be chosen in the same manner as for the numpy interfaces.

Dynamic library detection at build and run time

setup.py has been overhauled to dynamically detect the variants of FFTW that are present. Previously single, double and long double libraries were all required at build time. Now, compilation will attempt to detect which
variants are present and compile based on that.

It also now possible to specify an additional search path for the fftw libraries by setting the environment variable PYFFTW_LIB_DIR.

One caveat is that dynamic library detection is not used by default on the Windows platform, as the default assumption is that on Windows, a full set of precompiled libraries have been downloaded from fftw.org. Alternatively, if the environment variable PYFFTW_WIN_CONDAFORGE is defined, dynamic detection of
libraries named fftw3.dll, fftw3f.dll and fftw3l.dll is attempted. This is for compatibility with the CMake-based FFTW build used by conda-forge.

The builders and interfaces all detect at runtime which variants are available and select the most suitable precision for the input's dtype. For example, if single-precsion FFTW libraries are not available, double-precision FFTs will be
used to transform single-precision inputs. The PyFFTW test suite also detects at runtime which variants have been compiled and only runs tests against the available precisions.

OpenMP threading support

Building with OpenMP-based threading is also now supported. If both OpenMP and posix threaded libraries are found, the OpenMP variant will be preferred. If the user desires to instead link to posix threads by default, the
environment variable PYFFTW_USE_PTHREADS should be defined.

Custom Configuration of Planners and Interfaces

The new module pyfftw.config can be used to assign values for the default number of threads (via pyfftw.config.NUM_THREADS) and default FFTW planner effort (via pyfftw.config.PLANNER_EFFORT). It is also now possible to define the environment variables PYFFTW_NUM_THREADS and PYFFTW_PLANNER_EFFORT to determine the default values at import time.

Bugs Fixed

A platform-dependent bug that results in potentially overwriting a previously computed output upon repeated calls to the numpy interfaces was fixed (#199).

Fix to potential platform-dependent integer overflow in empty_aligned (#192).

rfftfreq is now present in the numpy fft interfaces for numpy >= 1.8 (#207)

Other changes

float16 inputs are now transformed using single rather than double precision.

The default planning for the numpy and scipy interfaces has changed from FFTW_MEASURE to FFTW_ESTIMATE. This results in faster planning. In cases where the same transform is to be repeated many times, it is likely advantageous to manually specify FFTW_MEASURE instead (or use the FFTW builders
to pre-plan the FFT).

FutureWarnings related to NumPy multiindexing in NumPy 1.15 are avoided by using more modern indexing conventions.

version number handling is now automatically handled by versioneer

All documentation is now built and hosted at Read the Docs (http://pyfftw.readthedocs.io).

Authors

• Frederik Beaujean +
• Dennis Brakhane +
• Henry Gomersall
• John Kirkham +
• Antony Lee +
• Gregory R. Lee
• Iblis Lin +
• Matthew D. Scholefield +
• Hsiou-Yuan (Herbert) Liu +

A total of 9 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully complete.

Version 0.10.4 release

The last couple of releases were a disaster. This should put things back into a rational state so I can revisit the work more carefully.

Version 0.10.3 release

Merge pull request #123 from hgomersall/master

Tweaked the appveyor release environment variable logic.

v0.10.2: Merge pull request #123 from hgomersall/master

Tweaked the appveyor release environment variable logic.