Re: simplicity vs. efficiency of algorithms in GSL

["Andrew W. Steiner" <awsteiner@gmail.com>]

My 2 cents:

I thought Brian's emphasis on ease of use and good documentation was
particularly important. IMHO, more than anything else that is what makes GSL
such a superb piece of work. It installs everywhere. It's easy to
understand, and
it simply works.

I'm a bit uncomfortable with the phrase
"just having everything", because I wouldn't want to see something like
root (root.cern.ch), which does indeed have everything...and it's
always sort of half
complete. That being said, including multidimensional quadrature is a good
idea, and there are definitely other things to be included.

And yes, a good quality C interface to LAPACK sounds fabulous.

There's no need to even mention NR, as I can't believe anyone really
takes that seriously anymore.

Take care,
Andrew

On Wed, Sep 24, 2008 at 8:07 PM, Gerard Jungman <jungman@lanl.gov> wrote:
>
> On Wed, 2008-09-24 at 22:15 +0100, Brian Gough wrote:
>> I mentally gave up on LAPACK as an option a long time ago.
>
> Sounds reasonable. I'm tired of waiting for them to produce
> something attractive. But what do we do?
>
>
>> The FLAME
>> library has more potential, it is LGPL'ed and faster than LAPACK, but
>> it does not have all the functionality [1].
>
> Interesting. Are we waiting for them to do something practical,
> like generate a feature-complete LAPACK replacement? I hope they do...
>
> More than that, I hope they produce an interface that makes sense.
> Enough sense that people are motivated to code to it.
>
>
>> Realistically I see the role of GSL as an alternative to Numerical
>> Recipes and other similar non-free libraries.  None of these have any
>> super features but they are still widely used.  As such, I would see
>> simplicity, ease of use and good documentation as priorities.
>
> I don't know about this "alternative to NR" philosophy. Those words have
> been used before; they make some sense, as far as they go. But that's
> really aiming pretty low. GSL is far from perfect, but, in my opinion,
> it is clearly better than NR in every way.
>
> As far as the range of functionality to encompass, I agree with
> Robert Brown; we should have everything. That doesn't mean we have
> to implement everything, we just have to know how it would fit in.
> I think figuring out how components fit together is most of the battle.
>
> For the same reason, simplicity vs efficiency is not the right argument.
> Experts should produce the the most efficient code, in some rational
> and usable form, and we should use it. The only thing that prevents us
> from doing this tomorrow is that, as far as I can tell, no expert has
> managed to produce what we need in a rational and usable form. For me,
> rational and usable means that it solves all those tedious problems
> that plague the fortran-to-anything-else interface. At least that
> would be a start.
>
> Of course, I like things to be neat and tidy; that's just me. Maybe
> other people don't mind having to cobble things together, but I have
> a very low threshold for that. There's no work I do that is so
> compelling that I don't care how painful it is to get the answer.
> And I always want better tools.
>
> I think we surpassed the "alternative to NR" goal some years ago.
> Now we should try to make the best possible thing. Period. And my
> reasons are very mercenary; if there were such a thing, then
> I would be able to use it.
>
> --
> G. Jungman
>
>
>