[SciPy-dev] Re: [SciPy-user] Current thoughts on future directions

[Pearu Peterson]

Hi,

To clarify few technical details:

On Wed, 9 Mar 2005, eric jones wrote:

> 1. How much of stats do we loose from removing fortran dependencies? 
> 2. I do question whether weave really be in this core?  I think it was in 
> scipy_core before because it was needed to build some of scipy.

At the moment scipy does not contain modules that need weave.

> 3. Now that I think about it, I also wonder if f2py should really be there -- 
> especially since we are explicitly removing any fortran dependencies from the 
> core.

f2py is not a fortran-only tool. In scipy it has been used to wrap also C 
codes (fft, atlas) and imho f2py should be used more so whenever possible.

> Travis Oliphant wrote:
>
>> 1) There will be a scipy_core  package which will be essentially what 
>> Numeric has always been (plus a few easy to install extras already in 
>> current scipy_core).   It will likely contain the functionality of (the 
>> names and placements will be similar to current scipy_core).
>> Numeric3  (actually called ndarray  or narray or numstar or numerix or 
>> something....)
>> fft      (based on c-only code -- no fortran dependency)

Hmm, what would be the default underlying fft library here? Currently in 
scipy it is Fortran fftpack. And when fftw is available, it is used instead.

>> linalg (a lite version -- no fortran or ATLAS dependency)

Again, what would be the underlying linear algebra library here?
Numeric uses f2c version of lite lapack library. Shall we do the same but 
wrapping the c codes with f2py rather than by hand? f2c might be useful 
also in other cases to reduce fortran dependency, but only when it is 
critical to ease the scipy_core installation.

>> stats  (a lite version --- no fortran dependency)
>> special (only c-code --- no fortran dependency)
>> weave
>> f2py?    (still need to ask Pearu about this)

I am not against it, it actually would simplify many things (for scipy 
users it provides one less dependency to worry about, f2py bug fixes and 
new features are immidiately available, etc). And I can always ship f2py 
as standalone for non-scipy users.

>> scipy_distutils and testing
>> matrix and polynomial classes
>> 
>> ...others...?

There are few pure python modules (ppimport,machar,pexec,..) in scipy_base
that I have heard to be used as very useful standalone modules.

>> We will push to make this an easy-to-install effective replacement for 
>> Numeric and hopefully for numarray users as well.   Therefore community 
>> input and assistance will be particularly important.
>> 
>> 2) The rest of scipy will be a package (or a series of packages) of 
>> algorithms.  We will not try to do plotting as part of scipy.  The current 
>> plotting in scipy will be supported for a time, but users will be weaned 
>> off to other packages:  matplotlib, pygist (for xplt -- and I will work to 
>> get any improvements for xplt into pygist itself),  gnuplot,  etc.

+1 for not doing plotting in scipy.

Pearu