Re: simplicity vs. efficiency of algorithms in GSL

[Gerard Jungman <jungman@lanl.gov>]

On Sat, 2008-09-27 at 08:10 +0200, Jochen Küpper wrote:
> 
> In C++ I am using mostly ODE solvers, linear algebra, local optimizers  
> (plus sf and const again, of course).
> It does bother me (and colleagues) a lot that neither the ODE solvers  
> nor the LA routines are really up to speed. My colleagues and myself  
> are really considering to abandon the GSL because we want better ODE  
> solvers and better eigenvalue/vector routines! And if the crucial  
> parts are not from GSL, why us it at all?

I agree. GSL needs to go to the next level, otherwise we're back
to cobbling parts together, and GSL becomes a frozen page in history.


> The name GNU Scientific Library implies it is meant for scientific  
> computing. Well, computational science (turned words around on  
> purpose), to a large extent, is solving large-to-big problems. Really  
> big problems probably have the resources to put together the best  
> algorithms for all their needs. For large problems that is often not  
> the case: We often implement the programs as a single person.

Exactly. A library should exist in order to make it possible for
one person to do the work needed to solve a large problem. That
is the target audience. Thank you for making this point very
clearly.


> There, we need the best libraries around. We like GSL, because it is  
> nicely documented and delivers routines for many (most) problems.  
> However, we are very much in need of getting improved algorithms!
> 
> For LA I would be very much in favor to have people (re)implement or  
> wrap fractions of LAPACK with a GSL-style interface. If there would be  
> a single nicely implemented routine, others would be easy to add.

We need an interface design. Maybe it's difficult, maybe not. I would
very much prefer that an expert created one for us. Somebody who has
used, or understands, all the parts of lapack.

Also, there is a danger that the thing we call lapack will shift
underneath us. Of course, the glob of code (on netlib for example)
will not change. But the underlying thing that you want to use may
change, as the "lapack" world moves forward. This means that there
has to be some rational approach to extending/updating the
interface design. Who will maintain this?

I was hoping that Dongarra et al. would create and maintain such
an interface. They have been promising this for some time. Does
anybody know what is happening with that?


> For ODE, for example, I am considering to test, and eventually switch  
> to, cvode (but I have not used it at all so far). I would be very  
> happy to not need to do this, but instead get improved ODE routines in  
> GSL and use my time for doing science!

I looked at CVODE many years ago. So I thought it was time to look
again, and to have a quick look at the the whole Sundials package,
which is new to me. Years ago, I thought the technical aspects were
good, but the design and packaging (and the code itself) were not
attractive. Also, it seemed to exist in one of these no-obvious-license
limbos. But it looks like they have made a lot of progress.
And it's an explicit BSD license now.

The main objection I had, those years ago, was the way CVODE
came with its own little linear algebra world. That is definitely
a design mistake, though you can see why they did it. That
still seems to be the case. I'm not sure how the end user can
use it as a research tool, if the linear algebra implementation
is essentially closed. (Of course you can always modify the
code, but that's not the point. The ability to modify should be
designed into the system, so you can replace/modify parts of
the machinery in a rational way, maybe through some kind of
framework design.) As a canned tool, it makes sense. But it
should be more than that.

However, it is possible that I do not understand the CVODE design.
For example, they claim that one of their goals was to allow users
to supply their own data structures. I'm not sure how that can
work.

I would enjoy hearing what anybody has to say about CVODE/Sundials.
Tell me why the design makes sense (or not).

Also, what is the right way to handle this dependency issue, which
occurs in GSL as well. ODE methods clearly rely on linear algebra,
so logically they should build on a foundational linear algebra
package. Having them carry their own implementations makes me
very queasy. Yet, we have no standard linear algebra interfaces
to program to.


> Please take this as a call that scientists need improved routines in a  
> GSL-quality and -breadth library.
> 
> I understand that this is a difficult problem, but that is what GSL  
> should aim at and what the FSF should support and push if they want a  
> scientific library!

Again, I agree. Unfortunately, I don't think there is any such thing
as "FSF support" or "push". As always, we're on our own. Just a handful
of people trying to make something better than what we had before.

GSL should definitely aim higher. But GSL is us... so what are
we going to do?

I have no personal love of computational linear algebra. But organizing
some linear algebra interfaces seems to be the number one problem
holding up our progress.


--
G. Jungman