From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2221 invoked by alias); 17 Dec 2009 22:50:41 -0000 Received: (qmail 2205 invoked by uid 22791); 17 Dec 2009 22:50:39 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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; Thu, 17 Dec 2009 22:50:33 +0000 Date: Thu, 17 Dec 2009 22:50:00 -0000 Message-ID: <87zl5hnrkh.wl%bjg@network-theory.co.uk> From: Brian Gough To: Rhys Ulerich Cc: gsl-discuss@sourceware.org Subject: Re: Where a generalized Richardson extrapolation routine would fit in GSL? In-Reply-To: <4a00655d0912161643k63868ac4i2577f618f6e2196@mail.gmail.com> References: <4a00655d0908201247g7d7bd9a1t466f4a66f08df4@mail.gmail.com> <4a00655d0911291536t5a11752fp27ab9c274148f822@mail.gmail.com> <4a00655d0911291538y9f29830v984d1a796fdd5d1@mail.gmail.com> <4a00655d0912131549w19638273nb51d723e9ddd9273@mail.gmail.com> <87d42ggnsv.wl%bjg@network-theory.co.uk> <4a00655d0912150931q4b34fd24p94594ed08857254f@mail.gmail.com> <87zl5ig7i0.wl%bjg@network-theory.co.uk> <4a00655d0912161643k63868ac4i2577f618f6e2196@mail.gmail.com> 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: 903dd5b017f0bb04f1e1d960733fb8ef 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-q4/txt/msg00067.txt.bz2 At Wed, 16 Dec 2009 18:43:44 -0600, Rhys Ulerich wrote: > > Ideally I'd like to start with a scalar version using normal C arrays, > > similar to the gsl_sum functions, for implementation simplicity. > > For API simplicity? Or simplicity of the underlying implementation? Where possible it is good to have an API that does not depend on gsl_vector and gsl_matrix as it makes it simpler to use (or reuse) the code from C programs with a minimal dependence on GSL. Implementing each routine to be minimal (without extra features) also makes life simpler. > There's just enough to the argument processing and general normtable > handling that it's easier to get good test coverage if there's one > implementation that does the whole enchilada and then everything else > sits as convenience wrappers. That prevents changes to one > convenience function from accidentally changing the interface's > semantics (especially for the 'k' handling). > > All that said, I'm happy to make the interface conform. Would you be > willing to take draft public API in gsl_extrap.h (inline below) and > change the functions and their signatures to resemble what you'd like? I will send that once I've looked at it a bit more.