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 <[EMAIL PROTECTED]> 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 > > >
