cblas and gsl (was: Re: Bessel function scaling + limited range?)

[John W. Eaton]

On  4-Feb-2008, Dmitri A. Sergatskov wrote:

| On Feb 4, 2008 4:07 PM, John W. Eaton <address@hidden> wrote:
| >  However, switching to GSL may not
| > be trivial, as it seems to rely on cblas (at least on my system) and I
| > think it would be best to use ATLAS and not also cblas.  If someone
| > would like to follow up on this, I'd suggest moving the discussion to
| > hte maintainers list.
| >
| 
| 
http://www.gnu.org/software/gsl/manual/html_node/Linking-with-an-alternative-BLAS-library.html
| 
| <<<<
| 
| 2.2.2 Linking with an alternative BLAS library
| 
| The following command line shows how you would link the same
| application with an alternative cblas library called libcblas,
| 
|      $ gcc example.o -lgsl -lcblas -lm
| 
| For the best performance an optimized platform-specific cblas library
| should be used for -lcblas. The library must conform to the cblas
| standard. The atlas package provides a portable high-performance blas
| library with a cblas interface. It is free software and should be
| installed for any work requiring fast vector and matrix operations.
| The following command line will link with the atlas library and its
| cblas interface,
| 
|      $ gcc example.o -lgsl -lcblas -latlas -lm

OK, I now see that the cblas interface is really just a thin wrapper
around the Fortran interface for the BLAS, so it can probably coexist
with the way we currently call BLAS and LAPACK functions in Octave.

Another potential problem is that the cblas interface uses int.  That
would be OK except when compiling Octave with --enable-64.  In that
case, we need integer parameters to be 8 bytes wide.  What is the
right way to handle this problem with cblas?

If we switch to GSL for Bessel functions, then we would no longer need
the libcruft/amos directory.  I would also propose using GSL functions
in place of the Fortran code that is currently in libcruft/slatec-fn.
That covers

  acosh  asinh  atanh  betai  erf  erfc  gamma  gammainc  lgamma

In addition to this change, maybe we should drop the LAPACK and BLAS
sources from Octave (but require them to be installed in order to
successfully configure Octave).  What about fftpack?  Should we simply
require FFTW in order to provide the fft function?

In any case, changes like these were not really planned for 3.1, so
perhaps we should delay them until 3.2.

jwe