[Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation

[Henry Gomersall]

On 2013-09-19 23:12, Christoph Gohlke wrote:
> On 9/19/2013 1:06 AM, Henry Gomersall wrote:
>> On 19/09/13 09:05, Henry Gomersall wrote:
>>> I've had feedback that this is possible. Give me a few hours and I'll
>>> see what I can do...
>> 
>> I mean that it builds under win 64-bit. I'll prob push a .exe.
>> 
>> Cheers,
>> 
>> Henry
> 
> It's probbly the wrong place to suggest/discuss this... To build PyFFTW
> with MSVC one could replace the C99 headers and types with their numpy
> counterparts, e.g. `double complex`->`np.complex128`. There would be no
> need for `complex.h` or `stdint.h`. IIRC, with MSVC the `long double`
> type is identical to `double`. PyFFTW will likely not work with mingw
> compiled libfftw3l-3.dll and msvc compiled numpy. Maybe an option to 
> map
> all fftwl functions to their fftw counterparts would work. That way it
> will also be possible to link PyFFTW to Intel's MKL (instead of
> libfftw3*-3.dll), which does not support `long double` types.
> 

Yeah, these are the problems I'm trying to sort out. One strategy is to 
simply leave out the long double transform schemes when
numpy.dtype('longdouble') == numpy.dtype('float64'), which means that 
pyFFTW will work just fine with the mingw dlls as both numpy.longdouble 
and numpy.float64 arrays would map to the double precision fftw 
functions. This _should_ be seamless and transparent to the user.

A remaining issue is that there would be an ABI incompatibility between 
pyFFTW and the (never called) fftwl binaries. It probably wouldn't 
matter in practice, but it would upset me. Perhaps using MSVC compiled 
FFTW is a better solution...

Henry