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

[Anne Archibald]

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.

Anne