From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19536 invoked by alias); 25 Sep 2008 03:07:29 -0000 Received: (qmail 19152 invoked by uid 22791); 25 Sep 2008 03:07:28 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.158) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Sep 2008 03:06:33 +0000 Received: by fg-out-1718.google.com with SMTP id e12so167111fga.0 for ; Wed, 24 Sep 2008 20:06:30 -0700 (PDT) Received: by 10.86.71.1 with SMTP id t1mr8231678fga.36.1222311989918; Wed, 24 Sep 2008 20:06:29 -0700 (PDT) Received: by 10.86.53.9 with HTTP; Wed, 24 Sep 2008 20:06:29 -0700 (PDT) Message-ID: <63c059b10809242006g418810f8y12d0d4add75fa130@mail.gmail.com> Date: Thu, 25 Sep 2008 03:07:00 -0000 From: "Andrew W. Steiner" To: gsl-discuss@sourceware.org Subject: Re: simplicity vs. efficiency of algorithms in GSL In-Reply-To: <1222301240.30638.146.camel@bellerophon.lanl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809221621.54890.emanuele.passera@treuropa.com> <20080922162507.GA29877@hippogriff.homeunix.org> <48D7E476.2010000@iki.fi> <20080922195029.GA9060@hippogriff.homeunix.org> <1222206451.30638.62.camel@bellerophon.lanl.gov> <1222301240.30638.146.camel@bellerophon.lanl.gov> Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00032.txt.bz2 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 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 > > >