[SciPy-dev] scipy status

eric jones eric at enthought.com
Thu Sep 19 02:46:30 CDT 2002

Hey Pearu,

> On Wed, 18 Sep 2002, eric jones wrote:
> > Hey group,
> >
> > I have a few days coming up here to work on getting a SciPy 0.2 out
> > door.  It looks like it is buiding and passing all test on windows,
> > I think it is doing OK on Linux.  Sun is close or finished (Skip?).
> >
> > What I'd like to know is if there are any other known issues that we
> > need to solve before pushing 0.2 out?
> >
> > FFT
> > Pearu, how are things on the fft changes?  I never heard back from
> > on the license issue.  I think we are in the clear to use his code,
> > he also seems to get quite exserised with people who cross him:
> >    http://cr.yp.to/distributors.html
> >
> > We are statically linking his code so the comments here about
> > it in the correct places doesn't seem to apply -- they look to be
> > at his executables not library files.
> >
> > My vote is to move ahead with using them and then remove them later
> > he does not like what we are doing.  We can back off again to
> > with the same functionality and also the fftw wrappers are still
> > for those wanting to use it and not constrained by the GPL.
> fftpack2 is almost complete in the sense that wrappers to C/Fortran
> libraries are finished, there are rather complete tests, and
> functions are documented. Right now I am fine-tuning differentiation
> transform that can be sensitive to numerical noise from FFT
> algorithm if the signal is very long (in my application I need the
> numerical noise level to be absolutely minimal and that depends on
> accuracy properties of fft libraries. Btw, djbfft turns out to be
> also the most accurate fft library compared to FFTPACK and FFTW).
> Anyway, fftpack2 is designed to use optimal FFT library combination
> different jobs. Currently, FFTPACK, FFTW, and DJBFFT libraries are
> supported. Last two are optional and used only if system_info.py
> them. It turns out that DJBFFT is fastest for power-of-two 1-D
> and  FFTW is superior for N-D transforms and non-power-of-two
> transforms. Some of the timings are included at the end of this

It looks like you've done some very good work here.  There are some very
big wins over the current code.  I'm excited about getting it into

> What fftpack2 is missing? I haven't implemented yet some of
> convenience functions such as fft2, hfft, fftshift, fftfreq, cont_ft,
> zeropad. They all are Python functions and can be copied from the
> fftpack. In addition, these functions need unittests.
> I think I can finish fftpack2 by this weekend so that it would be
> for review first as a stand alone package and if you are satisfied
> it can be committed to scipy.

Sounds good.

> About djbfft and scipy.
> djbfft builds from its makefile. This is fine under unix but I have no
> idea if this will be an issue for Windows. Could someone try it out on
> Windows? If it builds, then also test whether system_info.py can
detect it
> and may be adjust it accordingly?

Is it possible to dump the source into the tree and let distutils build
it?  That would be my preferred solution. 

> > How is linalg?  This is by far the biggest build headache, but it
> > seem to be working against atlas on windows and linux and against
> > and BLAS on Sun.
> linalg builds fine provided that ATLAS or LAPACK/BLAS are the latest,
> built/installed properly, and preferably there are no other atlas or
> lapack libraries installed on the system. I think a detailed SciPy
> HOWTO would be very useful to reduce the build headache.
> INSTALL.txt should be a starting point but there are still some
> instructions at the scipy site that people probably try out first and
> into problems.
> > Any other specific packages that need mentioning?
> I would mention packages that lack more or less complete unittests.


> Btw, I just noticed that importing scipy assumes that wxPython is
> installed and DISPLAY must be working. When trying to import scipy
from a
> different computer without X connection, I get:
> >>> import scipy
> Gtk-WARNING **: cannot open display:
> and python quits. Any idea how to fix this?

I removed plt from the _pkgs list in __init__.py.  This should fix it.
I had to do the same for gplt on windows.  I guess I need to check for
DISPLAY in gui_thread or wxplt or somewhere like that for the *real*
solution.  We'll mess with this in Chaco instead of here.  I think Dave
is about to pull the trigger on its release.  Within a few weeks, it
should do everything plt does and pretty much replace it.  I think gplt
and xplt will have to stick around for a while because they have quite a
bit more functionality still.

See ya,

More information about the Scipy-dev mailing list