This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSL 2.0 roadmap (one man's view)


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]