[SciPy-dev] FFTPACK and RandomArray

eric eric at scipy.org
Wed Feb 20 09:20:45 CST 2002


> On Wed, 20 Feb 2002, eric wrote:
>
> > > On Tue, 19 Feb 2002, eric wrote:
> > >
> > > > Just to fill everyone in, we're gonna be making fftw an "optional"
package
> > in
> > > > SciPy.  This is because its license doesn't fit with the rest of the
> > package.
> > > > FFTPACK provides pretty much a drop in replacement in functionality, so
no
> > > > capabilities are lost.  The only drawpack is that fftw is faster.  On
the
> > > > upside, it will simplify the build process, and the part of the pain
that
> > > > Fernando suffered today will be alleviated.
> > >
> > > It would be nice to keep things so that users can easily use one or the
> > > other though. Since fftw is GPL, for many that's ok and they may prefer to
> > > use fftw. Don't know how much extra work that would mean though.
> >
> > Well the wrappers will still be around, and they work quite well in the
current
> > state.
> > I don't know if they will still be in the CVS, but they will certainly still
be
> > available with instructions on how to build them on the SciPy site.  For
those
> > interested, it'll hopefully be a drop in replacement.  Afterall, they work
fine
> > now in SciPy, and I don't see the fft interfaces changing much.
>
> I am going to be definitely one user of fftw (because of its speed) and
> the pain that Fernando suffered with fftw can be certainly eased as we now
> know the workouts.
>
> But why do you want to throw the fftw wrappers out of scipy CVS? Does it
> violets any licence item if distributing wrappers (to GPL'ed
> codes) without distributing the corresponding libriaries?

No, just the binary disrtibutions.  The headache about keeping them in CVS
is the maintanance issue.  Trying to keep one library tested and working is hard
enough, having functional duplicates doubles the problem.

Still, I'm not opposed to keeping them in the CVS in something like a nondist
directory.  This is sorta how Python handles things.  That would keep the
wrappers around and let
them evolve with SciPy, but out of the way of the main development tree in an
"unsupported" section.

> And that with an addition check if the GPL library is present. If yes,
> then triggering the wrappers extension build and making scipy to use
> the fastest routiones available, though they may be GPL'ed?

Sure, this is fine with me.

So how does that plan sound -- move fftw into a nondist directory?

eric






More information about the Scipy-dev mailing list