Re: gslclapack

[Gerard Jungman <jungman at lanl dot gov>]

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 <jungman@lanl.gov>
Los Alamos National Laboratory