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

[Dmitri A. Sergatskov]

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?

>
> 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?

>
> jwe
>

Sincerely,

Dmitri.

p.s. there is gsl_sf package in octave-forge, but for the life of me I
I cannot figure out how to use it...
--