This is the mail archive of the
`gsl-discuss@sourceware.org`
mailing list for the GSL project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Rhys Ulerich <rhys dot ulerich at gmail dot com>*To*: Brian Gough <bjg at gnu dot org>*Cc*: gsl-discuss at sourceware dot org*Date*: Wed, 16 Dec 2009 18:43:44 -0600*Subject*: Re: Where a generalized Richardson extrapolation routine would fit in GSL?*References*: <4a00655d0908201247g7d7bd9a1t466f4a66f08df4@mail.gmail.com> <4a00655d0911291536t5a11752fp27ab9c274148f822@mail.gmail.com> <4a00655d0911291538y9f29830v984d1a796fdd5d1@mail.gmail.com> <m34ooa7qvr.wl%bjg@network-theory.co.uk> <4a00655d0912131549w19638273nb51d723e9ddd9273@mail.gmail.com> <87d42ggnsv.wl%bjg@network-theory.co.uk> <4a00655d0912150931q4b34fd24p94594ed08857254f@mail.gmail.com> <87zl5ig7i0.wl%bjg@network-theory.co.uk>

> Also, are the "exact/normtable" arguments essential or just for > convenience? If they can be computed easily by the user it would be > good to have only a minimal number of arguments in the base function. They're just for convenience. Computing the norms doesn't require difficult coding, but doing it in a storage and efficient way for the vector case requires computing those norms during the extrapolation process. It isn't difficult but it does require some index futzing. > 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? 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? That'll save me from needing to update the unit tests and documentation as we iterate to convergence. - Rhys The declarations from that last patch look like: int gsl_extrap_richardson_vector_step( gsl_vector * Ah, const gsl_vector * Aht, double t, double ki); int gsl_extrap_richardson_step( double * Ah, const double * Aht, double t, double ki); int gsl_extrap_richardson_vector( gsl_matrix * A, double t, const gsl_vector * k, gsl_matrix * normtable, const gsl_vector * exact); int gsl_extrap_richardson( gsl_vector * A, double t, const gsl_vector * k, gsl_matrix * normtable, double exact);

**Follow-Ups**:

**References**:**Re: Where a generalized Richardson extrapolation routine would fit in GSL?***From:*Rhys Ulerich

**Re: Where a generalized Richardson extrapolation routine would fit in GSL?***From:*Brian Gough

**Re: Where a generalized Richardson extrapolation routine would fit in GSL?***From:*Rhys Ulerich

**Re: Where a generalized Richardson extrapolation routine would fit in GSL?***From:*Brian Gough

**Re: Where a generalized Richardson extrapolation routine would fit in GSL?***From:*Rhys Ulerich

**Re: Where a generalized Richardson extrapolation routine would fit in GSL?***From:*Brian Gough

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |