From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22649 invoked by alias); 7 Sep 2009 15:10:34 -0000 Received: (qmail 22546 invoked by uid 22791); 7 Sep 2009 15:10:33 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,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; Mon, 07 Sep 2009 15:10:17 +0000 Date: Mon, 07 Sep 2009 15:10:00 -0000 Message-ID: From: Brian Gough To: GSL Discuss Mailing List Subject: Re: GSL 2.0 roadmap (one man's view) In-Reply-To: <1251414939.23092.82.camel@manticore.lanl.gov> References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 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: 6914e7daaa8c439e10a128cf92bda570 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: 2009-q3/txt/msg00036.txt.bz2 At Thu, 27 Aug 2009 17:15:39 -0600, Gerard Jungman wrote: > The GSL native fft implementations suffer in the same way that > the GSL native linear algebra implementations suffer. Better > solutions are available, from almost all points of view, and > the GSL implementations therefore detract from the GSL > cachet as a whole. "Serious users should use FFTW" is not > a good tagline for the sublibrary; see the discussion of > linear algebra above. In practice it seems like any solution is going come down to saying people should use FFTW (or LAPACK) one way or another. Either we could bundle it, or -- if we don't supply the existing GSL routines -- they could be forced to install it. Either way it doesn't seem like the result is actually much different from now. While getting packages via RPM/DEB is typically fine for desktop use, I think the ease of doing this in the wider world generally is underestimated: - if someone needs a version not available as an RPM/DEB - on other operating systems - for cross-compilation Consider an example of targetting an embedded system for data-collection with an ARM cpu where the vendor provides only an older version of GCC, without fortran. Based on my experience, this is a realistic scenario in industry. Currently GSL could be used easily in this scenario via cross-compilation. If we depended on external packages it would be much more difficult.