[SciPy-Dev] Scipy 1.0 roadmap

Christoph Deil deil.christoph@googlemail....
Tue Sep 24 08:29:45 CDT 2013


On Sep 24, 2013, at 1:28 PM, Nathaniel Smith <njs@pobox.com> wrote:

> On Mon, Sep 23, 2013 at 8:51 AM, Dag Sverre Seljebotn
> <d.s.seljebotn@astro.uio.no> wrote:
>> On 09/21/2013 08:57 PM, Ralf Gommers wrote:
>>> fftpack
>>> ```````
>>> Needed:
>>> 
>>>   - solve issues with single precision: large errors, disabled for
>>> difficult sizes
>>>   - fix caching bug
>>>   - Bluestein algorithm nice to have, padding is alternative
>> 
>> A battle-tested Bluestein is included in Martin Reinecke's C port of
>> FFTPACK.
>> 
>> https://github.com/dagss/libfftpack
>> 
>> As you can see in the readme there were a couple of changes to FFTPACK
>> to improve accuracy for large primes.
> 
> If this is nicely-licensed C code that provides a superset of
> scipy.fftpack's functionality, ought we to merge it into *numpy*.fft
> and deprecate scipy.fftpack? (I'm a little confused at what exactly
> the difference between the numpy and scipy modules is in this case,
> except that of course the scipy version needs a fortran compiler.)
> 
> -n

On that note … a thought for scipy 1.0 :

Does scipy absolutely need Fortran in general?
Or are there equivalent C or C++ packages that might be used instead?

Getting rid of Fortran code would simplify life for Mac users (and maybe Windows or even Linux).
I don't really know how much Fortran is used in scipy or libraries it depends on, or how much of a problem Fortran really is.
I'm just asking if getting rid of Fortran is an option even worth considering for scipy 1.0.

Christoph


> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



More information about the SciPy-Dev mailing list