[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)
Charles R Harris
charlesr.harris@gmail....
Tue Oct 13 11:42:20 CDT 2009
On Tue, Oct 13, 2009 at 10:12 AM, Anne Archibald
<peridot.faceted@gmail.com>wrote:
> 2009/10/13 Charles R Harris <charlesr.harris@gmail.com>:
> >
> > On Tue, Oct 13, 2009 at 8:14 AM, Pauli Virtanen <pav+sp@iki.fi<pav%2Bsp@iki.fi>>
> wrote:
> [snip]
> >> Anyway, you write the code, you call the shots :)
> >>
> >
> > Heh. I am looking for feedback before taking the plunge.
>
> Wow, lots of ideas! But I think before we can evaluate them we need to
> figure out what our requirements are. Here's a suggested list:
>
> (1) Simple. Simple to understand, simple to add new representations,
> even for users outside scipy.
> (2) Possible for users to subclass polynomials to provide polynomial
> objects with more features.
> (3) Polynomial objects should be able to detect and prevent operations
> between polynomials in different bases when appropriate (for example,
> you can substitute any kind of polynomial into a power-basis
> polynomial, or a Lagrange basis polynomial into anything).
> (4) Polynomial operations available as functions that operate on
> coefficient arrays rather than polynomial objects.
> (5) Possibly substantial data and methods attached to bases -
> orthogonal polynomial roots and weights, lists of points for Lagrange
> polynomials.
>
> Any others? Are all these really requirements?
>
>
I would add "massive code reuse".
> Here are some key questions:
>
> * Do we want the information about what representation a polynomial is
> in stored in the polynomial's class, in an explicit basis object the
> polynomial contains, or both?
>
I would say different representations, different classes, because different
representations don't mix; you can't even add the coefficients together.
This could be carried to an extreme, i.e., different scalings -> different
classes, but I think that degree of specificity is too much. Also no class
should need to know about any other class in order to work properly, it
should stand independently.
> * How should a user obtain a polynomial object?
>
>
I was thinking if you do 4), which is the fundamental requirement, then you
should be able get an appropriate class on top of that without any extra
work.
>
> My current implementation fails only (4), and could be modified by
> moving the code back into basis objects to satisfy (4). Then
> polynomials of all current representations could be of class
> Polynomial, with the basis information stored as an explicit basis
> object. Users obtain polynomials as
>
I really don't see any natural is-a relationship except for extending a
class, say by adding weights. Which is to say I don't see any natural base
class for all the different representations. I don't think inheritance is
the right concept here.
> "mybasis.polynomial(coefficients)"; the Polynomial constructor is also
> possible but raises an exception if misused. I'm not sure how best to
> discourage its use.
>
>
>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091013/3df0f536/attachment.html
More information about the Scipy-dev
mailing list