From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3552 invoked by alias); 27 Sep 2008 06:12:26 -0000 Received: (qmail 3542 invoked by uid 22791); 27 Sep 2008 06:12:25 -0000 X-Spam-Check-By: sourceware.org Received: from divok.RZ-Berlin.MPG.DE (HELO divok.rz-berlin.mpg.de) (141.14.131.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 27 Sep 2008 06:11:28 +0000 Received: from divok.rz-berlin.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1324DBCE83 for ; Sat, 27 Sep 2008 08:11:25 +0200 (CEST) Received: from [10.0.0.105] (dslb-088-072-003-139.pools.arcor-ip.net [88.72.3.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jochen) by divok.rz-berlin.mpg.de (Postfix) with ESMTPSA id 456992F08E for ; Sat, 27 Sep 2008 08:11:22 +0200 (CEST) Message-Id: <9ACA4123-675A-43C1-9200-F0AABB076117@googlemail.com> From: =?ISO-8859-1?Q?Jochen_K=FCpper?= To: GSL Discuss Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: simplicity vs. efficiency of algorithms in GSL Date: Sat, 27 Sep 2008 06:12:00 -0000 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> X-Mailer: Apple Mail (2.929.2) X-Seen-By: PP&B-Host divok X-PPB-Spam: Gauge=, Probability=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/msg00035.txt.bz2 Hi Everybody, On 26.09.2008, at 23:45, Brian Gough wrote: > At Wed, 24 Sep 2008 18:07:20 -0600, Gerard Jungman wrote: >> Sounds reasonable. I'm tired of waiting for them to produce >> something attractive. But what do we do? > > I think we should continue with simple linear algebra > implementations until there is a major change in the state of the > art, like being able to generate all LAPACK routines automatically > with the FLAME tools or similar. > >> 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. > > The history of the field, and computing in general, doesn't give > much cause for optimism here unfortunately. I really like GSL and use it a lot -- from C++ and from Python. I also was involved in early efforts to create a Python layer (PyGSL) and still use that a lot, i.e. for special functions and to get the constants. 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? 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. 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. 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! 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! Regards, Jochen -- Fritz-Haber-Institut der MPG -- Department of Molecular Physics -- Manipulation of Large Molecules Faradayweg 4-6 (C1.03) D-14195 Berlin, Germany phone: +49-30-84135686 fax: +49-30-84135892 http://www.fhi-berlin.mpg.de/mp/jochen