From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7228 invoked by alias); 25 Sep 2008 00:07:57 -0000 Received: (qmail 6943 invoked by uid 22791); 25 Sep 2008 00:07:56 -0000 X-Spam-Check-By: sourceware.org Received: from proofpoint3.lanl.gov (HELO proofpoint3.lanl.gov) (204.121.3.28) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Sep 2008 00:07:13 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint3.lanl.gov (8.13.8/8.13.8) with ESMTP id m8P07Bo9025402 for ; Wed, 24 Sep 2008 18:07:11 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id C2C911C3A2F for ; Wed, 24 Sep 2008 18:07:11 -0600 (MDT) X-CTN-5-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id AE7E81C3A42 for ; Wed, 24 Sep 2008 18:07:11 -0600 (MDT) Received: from [128.165.59.112] (bellerophon.lanl.gov [128.165.59.112]) by alvie-mail.lanl.gov (Postfix) with ESMTP id B55FB1FC01C for ; Wed, 24 Sep 2008 18:07:07 -0600 (MDT) Subject: Re: simplicity vs. efficiency of algorithms in GSL From: Gerard Jungman To: gsl-discuss@sourceware.org In-Reply-To: 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> Content-Type: text/plain Date: Thu, 25 Sep 2008 00:07:00 -0000 Message-Id: <1222301240.30638.146.camel@bellerophon.lanl.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 7bit X-CTN-5-MailScanner-Information: Please see http://network.lanl.gov/email/virus-scan.php X-CTN-5-MailScanner: Found to be clean X-CTN-5-MailScanner-From: jungman@lanl.gov X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7161:2.4.4,1.2.40,4.0.164 definitions=2008-09-24_14:2008-09-19,2008-09-24,2008-09-24 signatures=0 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/msg00031.txt.bz2 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