From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29380 invoked by alias); 17 Feb 2010 21:20:39 -0000 Received: (qmail 29363 invoked by uid 22791); 17 Feb 2010 21:20:38 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_05,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Feb 2010 21:20:33 +0000 Date: Wed, 17 Feb 2010 21:20:00 -0000 Message-ID: <87aav7r2u4.wl%bjg@network-theory.co.uk> From: Brian Gough To: Gerard Jungman Cc: GSL Discuss Mailing List Subject: Re: libflame version 4.0 announced In-Reply-To: <1266363451.8015.153.camel@manticore.lanl.gov> References: <4B3F0184.2030505@iki.fi> <1266363451.8015.153.camel@manticore.lanl.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Message-Mac: e713e2a140e8b7ef7fca201b86dc8c5b 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: 2010-q1/txt/msg00022.txt.bz2 At Tue, 16 Feb 2010 16:37:31 -0700, Gerard Jungman wrote: > (2) The LAPACK-like coverage seems reasonable. But I am not a good > judge of this. How much LAPACK functionality is covered in > this latest release? Obviously all the banded-matrix stuff > is out, since libflame does nothing with banded matrices. > But how complete is it regarding core functionality? The main omissions currently are eigenvalues and SVD. However, since everything in FLAME is derived automatically from a high-level description it should be easier for them to add new algorithms in the long run. The problems below are all fixable I am sure. > (4) According to the manual, libflame calls abort() when it encounters > a problem. As I have discussed before, this is brain-damaged. It > makes it hard for other library developers (us) to integrate > their thing into an existing error-handling system. They seem > to admit it is a problem, but it's probably a low priority > for them. How can we integrate this? > > (5) There are many configuration/build options. Is it feasible to > build and deploy several different versions (with and without > SuperMatrix, etc), from which a selection can be made at link > time, requiring no source-level changes in client code? > (d) There are several places where the API assumes C stdio. It looks > like some of these uses are internal (like FLA_Print_message > being used for error messages). This is brain-damaged, since > it makes it harder to integrate into other environments > (i.e. C++) where C stdio is not appropriate. It's ok to > have such "convenience" functions in the API, but they > should not be used internally. > > (e) The autotools build looks somewhat annoying. I'm really > tired of autotools. Obviously, the same is true of GSL.