[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cblas and gsl (was: Re: Bessel function scaling + limited range?)
From: |
Dmitri A. Sergatskov |
Subject: |
Re: cblas and gsl (was: Re: Bessel function scaling + limited range?) |
Date: |
Mon, 4 Feb 2008 19:04:44 -0600 |
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...
--