This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: gslclapack
> >>> On one hand, I'm jealous that lapack has a fancy routine, and react
> >>"let's
> >>> implement that for gsl too" and on the other hand, I think "why is gsl
> >>> re-implementing (what I believe is) a very standard library?"
> >>
> >>LAPACK is huge & tedious to install. GSL is meant to be easy to use -
> >>a dependency on lapack would be a pain.
> >
> >How do you find LAPACK being a pain? The public version of LAPACK has
> >been well tested and the design has been well thought out. It has a
> >very comprehensive test suite also.
>
> Is this an either/or proposition? Having its own lapack implementation
> just eliminates a dependency which I agree is desireable, and since the
> system-provided LAPACK often sucks as far as efficiency goes it also
> means that one CAN gradually start to tune up gsllapack. If the calls
> are the same, though, presumably one could link into an alternative
> library via suitable compile/link flags. I thought this was the way
> things were being done already, actually, so one could e.g. use ATLAS
> BLAS:
My hope was to encourage interchangeable implementations.
But it seems lapack routines cannot be used as drop-in replacements to implement
linalg_xxxx ones on account of the row-major, col-major business.
Is this true?
--
james bergstra
http://www-etud.iro.umontreal.ca/~bergstrj