Hey everyone,
For a while I've been thinking about how we can improve the
compatibility of `scipy.special` with Numba. There is a way to do that
currently by using `cython_special`:
https://github.com/numba/numba/issues/3086
but that has a few drawbacks:
(1) it's not very user friendly
(2) it relies on the (I think?) private implementation details of
Cython's `__pyx_capi__` (including the name mangling scheme used for
fused functions)
(3) it's clumsy for complex functions
I think (3) requires changes on the Numba side, e.g.
https://github.com/numba/numba/issues/3860
For (1) you could imagine us implementing another Numba specific API,
but that runs into some immediate issues:
- We'd need Numba as a dependency (which has been discussed:
https://mail.python.org/pipermail/scipy-dev/2018-March/022576.html)
- We don't want to just keep implementing new APIs
For those reasons I'd prefer to find another solution. In an ideal
world I'd like to solve (2) in such a way that it's easy for a
third-party library to wrap `cython_special` in Numba jitted
functions. There is a solution to that already that doesn't involve
`__pyx_capi__`: a third-party library writes some Cython glue that
exports PyCapsules of function pointers to the specializations of all
the `cython_special` functions and then you grab those using ctypes to
construct the jitted functions. For the Cython side of that see the
docs on specialization:
http://docs.cython.org/en/latest/src/userguide/fusedtypes.html#selecting-sp…
But that feels rather convoluted. In an ideal world it would be nice
to have an official way to grab the PyCapsules out of `__pyx_capi__`
instead of writing a new set of capsules yourself. Note that we run
into a similar problem with our own `LowLevelCallable`:
https://docs.scipy.org/doc/scipy/reference/generated/scipy.LowLevelCallable…
Getting the required name of the exported function for a fused
function requires searching through the mangled names for the one you
want.
Out of all that, my main questions are:
- Maybe I'm missing something obvious? Do people have better ideas for
improving compatibility?
- If not, would it be crazy to talk to the Cython folks about an
official method for getting the PyCapsules out of `__pyx_capi__`?
- Josh
Following on from some of the discussion surrounding my backend proposal and the discussion on gh-10175<https://github.com/scipy/scipy/issues/10175>; I've been working on adding a new scipy.fft submodule. This is now working, tested, documented and ready for review in gh-10238<https://github.com/scipy/scipy/pull/10238>.
The new submodule is almost a drop-in replacement for numpy.fft and scipy.fftpack, with a few exceptions:
* Does not include NumPy's Hermitian transforms (hfft, ihfft) (but would be simple to add)
* Uses numpy's conventions for rfft (complex array) instead of fftpack's (complex values packed into a real array)
* Convolutions and pseudo-differential operators from fftpack are not included
The new submodule adds pocketfft to implement the normal FFTs (not yet DCT and DST) which adds several new features beyond scipy.fftpack:
* long double transforms
* multi-dimensional real FFTs (rfftn)
* Orthonormal transforms (norm='ortho' argument)
* Bluestein's algorithm to avoid the worst case O(n^2) complexity of FFTPACK
A few implementation details worth noting:
* Unlike NumPy's version of pocketfft, this is C++ and uses templates to supporting the different floating point types
* pocketfft also uses pybind11 which both adds a new build-time dependency and requires C++11. I believe this is the first use of C++11 in SciPy.
* pocketfft has optional support for multithreading using OpenMP but this is currently disabled (and not compiled in at all).
And finally, there is the rather awkward issue that scipy.fft already exists and is an alias for the numpy.fft.fft function. Currently I've had to add a workaround to allow the module scipy.fft to be callable, as discussed in gh-10253<https://github.com/scipy/scipy/issues/10253>. This is only relevant to code that imports scipy.fft so I don't expect it to be used often, if at all. Hopefully this is a temporary solution and the NumPy functions can be removed from the scipy namespace in some future release, or at the very least the FFT functions can be removed.
Peter
The SciPy Conference <https://www.scipy2019.scipy.org/> approaches! Who
would be interested in a sprint <https://www.scipy2019.scipy.org/sprints>?
Can you participate in-person or virtually?
We don't necessarily need a theme, but would you like to recruit help for
something in particular?
If you already registered a sprint on behalf of the SciPy library, please
let me know. Otherwise, I can register (and I'll ask to be located near
NumPy so people don't have to choose one or the other).
Matt
I am pleased to announce release 2019.2 of SfePy.
Description
-----------
SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method or by the
isogeometric analysis (limited support). It is distributed under the new BSD
license.
Home page: http://sfepy.org
Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/
Git (source) repository, issue tracker: https://github.com/sfepy/sfepy
Highlights of this release
--------------------------
- improved support for time-dependent homogenization problems,
- Python 3.7 compatibility
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
---
Contributors to this release in alphabetical order:
Robert Cimrman
Jan Heczko
Lubos Kejzlar
Vladimir Lukes
