Re: 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 6:35 PM, John W. Eaton <address@hidden> wrote:
| 
| >
| > 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?
| >
| 
| How does it differ from the current situation with lapack/blas/atlas?
| 
| > 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
| >
| 
| I am all for it. The less cruft the better.
| I think we discussed the use of gsl for some of the
| gamma functions.
| 
| > 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?
| 
| Why not? Are there platforms where compiling fftw is harder than fftpack?

Yes, I'd think fftpack is always easier to build than fftw since
fftpack is just 16 Fortran 77 functions that are all currently
included with Octave.

| > In any case, changes like these were not really planned for 3.1, so
| > perhaps we should delay them until 3.2.
| 
| You are the boss :), but I honestly do not see why would it be such
| a big deal. It does not seem to break any existing API or
| other octave internals. Or perhaps you meant to say 3.0.2?

No, I meant 3.2.  I'm trying to stay focused on the original goals for
3.1 so we can have a new release in 6-8 months rather than 6-8 years.

jwe