From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25190 invoked by alias); 22 Sep 2008 19:48:06 -0000 Received: (qmail 25180 invoked by uid 22791); 22 Sep 2008 19:48:05 -0000 X-Spam-Check-By: sourceware.org Received: from qmta09.emeryville.ca.mail.comcast.net (HELO QMTA09.emeryville.ca.mail.comcast.net) (76.96.30.96) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 22 Sep 2008 19:47:20 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id Hn5C1a00C16AWCUA9vnKCA; Mon, 22 Sep 2008 19:47:19 +0000 Received: from hippogriff.homeunix.org ([75.70.82.180]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id HvnH1a00o3tRyZn8SvnJL8; Mon, 22 Sep 2008 19:47:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=eDGWpmOghtsA:10 a=QDZPgExL_ugA:10 a=Zi4Ez9ASHnt6jNYVG8QA:9 a=FE_sju1ij0MJLM5M6W4A:7 a=s4ltixl3hdlhy6UXk9RQnhCigdUA:4 a=MxZ3bB5I4kYA:10 Received: by hippogriff.homeunix.org (Postfix, from userid 1000) id D61A4CB6CD; Mon, 22 Sep 2008 13:50:29 -0600 (MDT) Date: Mon, 22 Sep 2008 19:48:00 -0000 From: Patrick Alken To: Tuomo Keskitalo Cc: Patrick Alken , gsl-discuss@sourceware.org Subject: Re: simplicity vs. efficiency of algorithms in GSL Message-ID: <20080922195029.GA9060@hippogriff.homeunix.org> References: <200809221621.54890.emanuele.passera@treuropa.com> <20080922162507.GA29877@hippogriff.homeunix.org> <48D7E476.2010000@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D7E476.2010000@iki.fi> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) 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/msg00027.txt.bz2 > About this point: I have been wondering where the balance of GSL should > be on simplicity vs. efficiency of the code. Of course, even a simple > algorithm is better than none, but I think it would be good to offer > efficient routines in GSL. If somebody publishes a well written, > efficient eigenvalue algorithm, would it get included in GSL? Or would > it be better off as an extension library? I think it depends on how simple and easy to understand it is. The algorithm in Golub and Van Loan is relatively simple and someone who is interested could read that book and then look at the GSL code and understand what is going on fairly easily. A year or so ago I tried to implement the current LAPACK algorithm for nonsymmetric eigenvalues, called the "Small Bulge Agressive Early Deflation" algorithm. This algorithm is easily 50-70% faster than the current GSL algorithm however it is extremely complex and it would take a non-expert several weeks to understand what the code is doing. Since that algorithm is available in LAPACK, a free library, I really don't see the need to put faster more complicated algorithms in GSL since LAPACK already has the fastest algorithms currently available. However if you want to implement these as extensions some would certainly find that useful. Patrick Alken