[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)

[Anne Archibald]

2009/10/9 Charles R Harris <charlesr.harris at gmail.com>:
>
>
> On Fri, Oct 9, 2009 at 11:08 AM, Anne Archibald <peridot.faceted at gmail.com>
> wrote:
>>
>> 2009/10/9 Charles R Harris <charlesr.harris at gmail.com>:
>> >
>> > I'm thinking that instead of a wrapper class what we want is essentially
>> > a
>> > class template replicated with different values for, i.e.,
>> > multiplication,
>> > division, etc. One way to do that in python is with a class factory. For
>> > example
>> >
>>
>> I see that this is possible, but I'm not sure I see why it's a good idea.
>>
>> We need basis objects, since even apart from any code, bases can
>> contain substantial amounts of information. For example, if someone
>> wants to work with the Lagrange interpolating polynomial on a set of
>> points, the natural basis is the Lagrange basis on those points, so
>> the polynomial must remember the list of points. Storing that in every
>> polynomial is inefficient, not just in terms of space but also because
>> basis comparisons - necessary for type-safety on every operation -
>> would have to actually go out and compare all the points.
>>
>> So every polynomial needs to contain (a reference to) the basis it's
>> defined on, and there must be a type hierarchy of bases. But if that
>> type hierarchy exists, why have a hierarchy of polynomials? After all,
>> the algorithms defined depend on the basis, rather than any feature of
>> the individual polynomial, and a polynomial is completely defined by
>> its coefficients and the basis.
>>
>> If you're concerned that the polynomial class exists without any real
>> code inside it, well, that's a bit awkward, I agree. But if we have
>> basis objects and polynomial objects, the code has to go in one or the
>> other, and it seems more natural to put it in the basis objects. In a
>> way this is similar to the design of your Chebyshev class - you have a
>> collection of functions that act on bare coefficient arrays (in my
>> design they're in a class, in yours they're module functions) and a
>> wrapper class whose code is only there to provide an easy-to-use
>> object-oriented interface. And the wrapper class is not completely
>> trivial - it handles checking basis equality (in principle it could
>> check compatibility, if that turns out to be useful), scalar
>> multiplication, and an operator-friendly interface.
>>
>> In object-oriented buzzword-speak, rather than using (possibly
>> multiple) inheritance to provide features using an is-a relationship,
>> I'm using inclusion to provide a has-a relationship. Code reuse
>> through inheritance will apply at the level of bases, rather than at
>> the level of individual polynomials.
>> brcuase
>
>
> It's not inheritence, it's a class templaate.  Because classes are objects
> in python you can return them from functions.with a defined enviroment.
> Another way to look at it is completions. A basis would just be another
> passed parameter. and the class code would still only heed to be written
> once for all the different types of polynnomial basis.. I think it is a
> cleaner way to go.

I don't think I understand what you're getting at, then. In your
design, where would the code to implement, say, evaluation of
polynomials in the Lagrange basis go? In the Lagrange basis object? In
the polynomial factory function? In separate toplevel functions?

Maybe it would help to write a mockup, with just one or two functions,
based on the scikits.polynomial code? If you'd like I can add you as a
collaborator on github. (I'm a little new to git, so please bear with
me as I figure out how I'm supposed to do things.)

Anne