At Thu, 27 Aug 2009 17:15:39 -0600, Gerard Jungman wrote: > The GSL native fft implementations suffer in the same way that > the GSL native linear algebra implementations suffer. Better > solutions are available, from almost all points of view, and > the GSL implementations therefore detract from the GSL > cachet as a whole. "Serious users should use FFTW" is not > a good tagline for the sublibrary; see the discussion of > linear algebra above.
In practice it seems like any solution is going come down to saying people should use FFTW (or LAPACK) one way or another. Either we could bundle it, or -- if we don't supply the existing GSL routines -- they could be forced to install it. Either way it doesn't seem like the result is actually much different from now. While getting packages via RPM/DEB is typically fine for desktop use, I think the ease of doing this in the wider world generally is underestimated: - if someone needs a version not available as an RPM/DEB - on other operating systems - for cross-compilation Consider an example of targetting an embedded system for data-collection with an ARM cpu where the vendor provides only an older version of GCC, without fortran. Based on my experience, this is a realistic scenario in industry. Currently GSL could be used easily in this scenario via cross-compilation. If we depended on external packages it would be much more difficult.
