Wed Mar 29 00:33:00 GMT 2006
On Tue, 2006-03-28 at 12:48 +0100, Brian Gough wrote:
> James Bergstra writes:
> > 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.
This is too cheap an answer. It also smells too much like the
old "XYZ package is too large and complicated, we just need
to build our own" syndrome.
And there is absolutely no reason why "the right way"
should be in conflict with "easy to use". For example,
I think the way GSL does the cblas interface, with a
link-time resolution, is very easy to use, and it
seems like a pretty good approximation to the right way.
(Well, it was my idea, so of course I think so...).
There have been several comments on the original message, so I'll
try not to labor over the same points. Here is what I think is obvious:
- gsl_linalg is basically a "mistake"; it satisfies the immediate
need of a certain class of users, but in so doing it hardwires
an unattractive an inflexible scheme in place for everyone; even
if you don't use it, you pay for it because it costs development
time and takes up intellectual real estate. And I wrote a lot of
it, so I think my opinion counts for something in this regard.
It was my mistake.
- GSL should provide an interface to lapack; it need not supersede
the gsl_linalg implementation, but can coexist with it. It can
be done in such a way that users can choose an appropriate
implementation at link time, in the same way that the blas
interface works. The only issue here is that we need to work
out how to satisfy its blas dependencies. As long as it
works in terms of cblas conformant calls, the dependencies
will be resolved correctly at link time when the desired
cblas implementation is picked up. If it works some other
way, like deferring to an underlying fortran lapack
implementation which uses fortran-style name lookup
for blas functions, then that would makes things
less coherent and this would need to be fixed up
in some way. I am hoping that the clapack standard
says something about this situation; after all, it
ought to be designed to work well with cblas.
- Lapack may be difficult to build. I wouldn't know, since I
never had to build it. I just install the RPM. As someone
pointed out, the efficiency of lapack is essentially inherited
from the underlying blas, so this out-of-the-can solution
should be ok for nearly everyone. Note that I do not consider
this to be an argument against having a GSL interface, since
such an interface should take care of the GSL house-keeping
chores, marshalling the arguments in the correct way for the
more low-level interface, and dealing with error handling.
It would be a thin interface, but still necessary.
- It is _always_ better to reuse a general and mature solution
like lapack than to create a half-baked substitute, no matter
how good your intentions or how limited the apparent scope
of the need. Even if there is no "efficiency" gained in using
a real lapack implementation, many things are gained. These
include complete coverage of methods, a large suite of tests,
a robustness that only comes from the real thing, because of
the large existing user base, and the elimination of maintenance
for a large chunk of specialty code.
Some historical data:
- We discussed creating a lapack interface, similar to the
blas interface. The basic limitation was lack of manpower
and some statements about the difficulty of dealing with
workspace allocation/management, which I did not understood
at the time, and still don't understand.
- There was some concern about evolving standards. These
decisions were made for GSL around 1998, when even cblas
was just a draft concept. It was not clear what was in
the future for lapack interfaces, so we decided to
sidestep the problem.
- There was some concern about licensing. This is mentioned
in the TODO file, but I do not know what the question is.
I doubt that this can be a serious problem.
If somebody dropped a working lapack interface on the table,
I would certainly want to put it in GSL. It's a clear win.
The only hard part is that we do need a reference implementation
of some sort to ship with GSL, like the gslcblas component which
ships, so that "casual" users can hit the ground running. Such
an implementation can coexist with gsl_linalg, and gsl_linalg
can be eventually deprecated.
This whole gsl_linalg thing is kind of embarrassing. People
expect to see a coherent picture for linear algebra, at the
very least a complete and functional lapack interface.
Instead, the GSL situation just smells a little fishy,
and there is a strong sociological argument for
cleaning up the mess, in order not to scare away
potential serious users.
Gerard Jungman <email@example.com>
Los Alamos National Laboratory
More information about the Gsl-discuss