Re: FFTW 3.0 beta available

[Gerard Jungman <jungman at lanl dot gov>]

I haven't seen Brian respond publicly to your second message,
so I thought I should say some things.


On Mon, 2003-03-17 at 22:12, Steven G. Johnson wrote:

>  What are your plans for the FFTs in GSL, then?  Deprecation?

Deprecation is too strong a term. Anyway, there are two issues. Having
a native GSL implementation is not a bad thing, although it has the
potential to create some confusion. Ideally I would like to see a
mechanism like the gslcblas/external-cblas one, where GSL provides
an interface but the user can choose whether to use the native gslcblas
library or an external cblas implementation, at link time.

So, what we really need is a set of interfaces which are general
enough to encompass FFTW and the native GSL implementation. This
probably means we can just use the FFTW interfaces as a base.
But there will almost certainly be some issues to sort out.
One the one hand I feel a little saddened that the FFTW interface
hides everything behind the (essentially) opaque fftw_plan object;
for instance, I would have hoped that the plan would be separate
from the data. Maybe I misunderstand the philosophy.
Anyway, it looks like any general interface will
have to have the same design. On the other hand, this sort of
encapsulation makes it easier to use and to wrap; it is not
a big deal.

Furthermore, I don't see any reason to hide or deprecate the current
GSL interfaces; they can be used by the more general wrapper. The
small amount of confusion which this will create can be offset by
good documentation, including examples of how to use an external
implementation (FFTW).


> One thing that might be quite useful would be if you guys would implement
> (or collect from somewhere) the various windowing functions and things
> that people use to pre/post-process FFTs for spectral estimation,
> etcetera, in DSP.  (We aren't DSP experts ourselves and prefer to stick
> with the pure transforms.)

This is a good idea, as long as we have a reasonable plan for what to
include and what to leave out. The hardest part is deciding what to
leave out and sticking with that decision.


> I think the GSL project is ideally suited to fulfill a role much like that
> of the GNU project in creating a free Unix replacement.  GNU started by
> looking at the existing free tools (such as LaTeX and X11), and
> systematically identified gaps in what was available and filled them
> (including writing glue programs like Texinfo).  In the same way, I would
> suggest that GSL should start with the best existing free numerical code,
> such as LAPACK and ATLAS/BLAS for linear algebra, and then systematically
> fill in the gaps and create glue if necessary.[*]

I absolutely agree that we need a "GNU Scientific Environment".
GSL itself is really intended to be one component of such an
environment (although a central one because of the need for consistent
interfaces), rather than the only entry point for it.
Of course, we can't claim that this was clear in our
minds from the start; GSL has evolved since it began, more than
seven years ago. So GSL still needs some real work to realize
this component-wise view.

At some level, we knew that we would have to implement
a bunch of bits and pieces, and we needed a loosely organized project
in which to drop them, so that those bits and pieces could start
being used and debugged, etc. That is certainly how I see GSL-1.x.
In 1997 it was not at all clear what a more general environment might
look like, and we needed to start somewhere. There was some idea at the
time (still expressed in the documentation and design document) that it
should be a very loosely coupled set of libraries with a strong
"numerical recipes" flavor. This bothered me from the start; as soon
as you realize that you need to use some library components in the
implementation of other library components, the over-simplification
of loose coupling evaporates. I think we reached some compromise
over this, but it is far from ideal.

If we are going to be serious about the "GNU Scientific Environment",
then we will need to have some concrete and reasonable notions of
how things do get coupled together. I hope that the GSL-1.x experience,
especially with BLAS and now with FFTW, will be enough to get us going
in the right direction. The other big external object is LAPACK...
see below.


> Like GNU/Linux, there is
> also a need for prepackaged distributions that include all relevant
> software, documentation, and build scripts.

This is a really big deal, and it will have to be a major force
in the design of any components and wrappers. These things have to
work well from top to bottom, from the numerical aspects all the
way up through the build and install process.


> Reading the GSL documentation, it's not clear to me whether this is your
> goal, or whether you are going for a more "Numerical Recipes" approach of
> one-stop shopping and re-implementation (instead of achieving a similar
> goal by packaging and documenting various code and libraries in one
> place).

I hope the above at least partly answers this. In short, GSL-1.x is a
mixture of the two, with a heavy lean toward "numerical recipes"
because of the history of its development. Parts of GSL will continue
that way in perpetuity, like the special functions, which are kind of
naturally self-contained. But other parts will have to grow up and
learn to talk with the rest of the world.

The goals for GSL-1.x were to fill a shopping cart with generic
numerical tools, solving as many local problems as we could. The
main goal for GSL-2.x must be to organize all these tools together
and make a real attempt to solve the global problems. Of course,
this is the step that kills a large fraction of software projects,
so we will need to be well-prepared to succeed.


> The NR approach leaves you with a lot of work re-implementing
> existing free code, since I'm sure you don't want to emulate NR's record
> of poor-to-mediocre implementations.

Again, it's a mixed bag. Some of GSL is straight re-implementation of
high quality code. Some has the look-and-feel of "numerical recipes",
but with improved implementations. And, of course, there are a few
embarrassing shady corners (for example, I have a strong urge to
remove the implementation of the confluent hypergeometric function;
objectively, that code  is a failed experiment).


> I get a mixed message when you
> present your own code and then say "but go to FFTW if you are
> serious," because I know that you guys are serious too.

I know what you mean. I try not to make such statements. I think this
type of statement should be taken as shorthand for the following:
"GSL ffts are a well understood re-implementation of high quality
code, and you should feel good about using them. However, we need to
do a better job in interfacing the GSL world to high-performance
implementations such as FFTW. Until we get around to doing this,
and if you really need the extra performance and flexibility,
you have to solve the interface problem on your own. We don't
feel good about this either, but it will take time for us to
do it right."

Long-winded, but accurate.


> > Where performance is an issue I'd recommend that people write their
> > code to call FFTW directly.  But if someone writes a wrapper to make
> > GSL FFT calls use FFTW I'd be happy to make it available somewhere.
> 
> Probably, that's not very practical to do efficiently, at least not with
> the current GSL interface and with FFTW 3, since in FFTW 3 you need to
> create a different plan if you e.g. change the stride.

Yup. On closer examination, these problem domains always turn out to be
more complex than we thought. That's why we will need better interfaces.


> What might be nice would be to simply document directly the FFTW calls
> analogous to the GSL calls (and in general, provide one-stop shopping for
> introductory documentation to best-of-breed free libraries).

Yes, it would be good to help people explicitly. Like much of the
documentation, I'll defer to Brian (I admit, I am a real problem-boy
when it comes to documentation).


> [*] For example, it would be great to have a raw clapack interface,
> analogous to the cblas interface.

I know Brian looked into this. Based on what he learned we decided
to postpone a clapack companion for the cblas interface. As I recall,
the main issue was how to deal with the workspace management issues,
which greatly complicate things. On the other hand, this may have
been a serious issue only for wrapping the fortran implementation;
I don't recall the details. That was about 4 years ago.
This needs to be looked at again, and it will have to be
solved as part of GSL-2.x.


Your original question:
> Is there any interest in calling FFTW from GSL?

In case Brian's response wasn't clear, the answer is definitely 'yes'.
We have to make it possible to do this in an easy way, preferably
allowing the user to defer the decision to link time, like with
cblas. We'll have to see what we can do.


Thanks for the message, and for FFTW.


-- 
Gerard Jungman <jungman at lanl dot gov>
Los Alamos National Laboratory