This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: simplicity vs. efficiency of algorithms in GSL


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]