[SciPy-dev] scipy status

[eric jones]

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
the
> > door.  It looks like it is buiding and passing all test on windows,
and
> > 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
djb
> > on the license issue.  I think we are in the clear to use his code,
but
> > 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
installing
> > it in the correct places doesn't seem to apply -- they look to be
aimed
> > at his executables not library files.
> >
> > My vote is to move ahead with using them and then remove them later
if
> > he does not like what we are doing.  We can back off again to
fftpack
> > with the same functionality and also the fftw wrappers are still
around
> > 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
high-level
> 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
for
> different jobs. Currently, FFTPACK, FFTW, and DJBFFT libraries are
> supported. Last two are optional and used only if system_info.py
detects
> them. It turns out that DJBFFT is fastest for power-of-two 1-D
transforms
> 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
message.

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
scipy.

> 
> 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
current
> fftpack. In addition, these functions need unittests.
> 
> I think I can finish fftpack2 by this weekend so that it would be
ready
> for review first as a stand alone package and if you are satisfied
then
> 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. 

> 
> > LINALG
> > How is linalg?  This is by far the biggest build headache, but it
does
> > seem to be working against atlas on windows and linux and against
LAPACK
> > 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
build
> HOWTO would be very useful to reduce the build headache.
> INSTALL.txt should be a starting point but there are still some
obsolete
> instructions at the scipy site that people probably try out first and
get
> into problems.
> 
> > Any other specific packages that need mentioning?
> 
> I would mention packages that lack more or less complete unittests.

Yes.

> 
> 
> 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,
Eric