From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21575 invoked by alias); 7 Oct 2008 21:14:05 -0000 Received: (qmail 21564 invoked by uid 22791); 7 Oct 2008 21:14:04 -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; Tue, 07 Oct 2008 21:13:20 +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 m97LDGYT010110 for ; Tue, 7 Oct 2008 15:13:17 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id EF8A5240FF9 for ; Tue, 7 Oct 2008 15:13:17 -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 D2223240FBA for ; Tue, 7 Oct 2008 15:13:17 -0600 (MDT) Received: from [128.165.59.112] (bellerophon.lanl.gov [128.165.59.112]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 89A101FC01B for ; Tue, 7 Oct 2008 15:13:09 -0600 (MDT) Subject: Re: simplicity vs. efficiency of algorithms in GSL From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: <9ACA4123-675A-43C1-9200-F0AABB076117@googlemail.com> 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> <9ACA4123-675A-43C1-9200-F0AABB076117@googlemail.com> Content-Type: text/plain; charset=UTF-8 Date: Tue, 07 Oct 2008 21:14:00 -0000 Message-Id: <1223413980.14338.96.camel@bellerophon.lanl.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 8bit 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-10-07_10:2008-10-06,2008-10-07,2008-10-07 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-q4/txt/msg00003.txt.bz2 On Sat, 2008-09-27 at 08:10 +0200, Jochen Küpper wrote: > > In C++ I am using mostly ODE solvers, linear algebra, local optimizers > (plus sf and const again, of course). > It does bother me (and colleagues) a lot that neither the ODE solvers > nor the LA routines are really up to speed. My colleagues and myself > are really considering to abandon the GSL because we want better ODE > solvers and better eigenvalue/vector routines! And if the crucial > parts are not from GSL, why us it at all? I agree. GSL needs to go to the next level, otherwise we're back to cobbling parts together, and GSL becomes a frozen page in history. > The name GNU Scientific Library implies it is meant for scientific > computing. Well, computational science (turned words around on > purpose), to a large extent, is solving large-to-big problems. Really > big problems probably have the resources to put together the best > algorithms for all their needs. For large problems that is often not > the case: We often implement the programs as a single person. Exactly. A library should exist in order to make it possible for one person to do the work needed to solve a large problem. That is the target audience. Thank you for making this point very clearly. > There, we need the best libraries around. We like GSL, because it is > nicely documented and delivers routines for many (most) problems. > However, we are very much in need of getting improved algorithms! > > For LA I would be very much in favor to have people (re)implement or > wrap fractions of LAPACK with a GSL-style interface. If there would be > a single nicely implemented routine, others would be easy to add. We need an interface design. Maybe it's difficult, maybe not. I would very much prefer that an expert created one for us. Somebody who has used, or understands, all the parts of lapack. Also, there is a danger that the thing we call lapack will shift underneath us. Of course, the glob of code (on netlib for example) will not change. But the underlying thing that you want to use may change, as the "lapack" world moves forward. This means that there has to be some rational approach to extending/updating the interface design. Who will maintain this? I was hoping that Dongarra et al. would create and maintain such an interface. They have been promising this for some time. Does anybody know what is happening with that? > For ODE, for example, I am considering to test, and eventually switch > to, cvode (but I have not used it at all so far). I would be very > happy to not need to do this, but instead get improved ODE routines in > GSL and use my time for doing science! I looked at CVODE many years ago. So I thought it was time to look again, and to have a quick look at the the whole Sundials package, which is new to me. Years ago, I thought the technical aspects were good, but the design and packaging (and the code itself) were not attractive. Also, it seemed to exist in one of these no-obvious-license limbos. But it looks like they have made a lot of progress. And it's an explicit BSD license now. The main objection I had, those years ago, was the way CVODE came with its own little linear algebra world. That is definitely a design mistake, though you can see why they did it. That still seems to be the case. I'm not sure how the end user can use it as a research tool, if the linear algebra implementation is essentially closed. (Of course you can always modify the code, but that's not the point. The ability to modify should be designed into the system, so you can replace/modify parts of the machinery in a rational way, maybe through some kind of framework design.) As a canned tool, it makes sense. But it should be more than that. However, it is possible that I do not understand the CVODE design. For example, they claim that one of their goals was to allow users to supply their own data structures. I'm not sure how that can work. I would enjoy hearing what anybody has to say about CVODE/Sundials. Tell me why the design makes sense (or not). Also, what is the right way to handle this dependency issue, which occurs in GSL as well. ODE methods clearly rely on linear algebra, so logically they should build on a foundational linear algebra package. Having them carry their own implementations makes me very queasy. Yet, we have no standard linear algebra interfaces to program to. > Please take this as a call that scientists need improved routines in a > GSL-quality and -breadth library. > > I understand that this is a difficult problem, but that is what GSL > should aim at and what the FSF should support and push if they want a > scientific library! Again, I agree. Unfortunately, I don't think there is any such thing as "FSF support" or "push". As always, we're on our own. Just a handful of people trying to make something better than what we had before. GSL should definitely aim higher. But GSL is us... so what are we going to do? I have no personal love of computational linear algebra. But organizing some linear algebra interfaces seems to be the number one problem holding up our progress. -- G. Jungman