[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)
Charles R Harris
Fri Oct 9 03:01:39 CDT 2009
On Thu, Oct 8, 2009 at 1:03 PM, Anne Archibald <firstname.lastname@example.org>wrote:
> 2009/10/8 Charles R Harris <email@example.com>:
> > Hi Anne,
> > On Thu, Oct 8, 2009 at 9:37 AM, Anne Archibald <
> > wrote:
> >> 2009/10/7 David Goldsmith <firstname.lastname@example.org>:
> >> > Thanks for doing that, Anne!
> >> There is now a rough prototype on github:
> >> http://github.com/aarchiba/scikits.polynomial
> >> It certainly needs more tests and features, but it does support both
> >> the power basis and the Lagrange basis (polynomials represented by
> >> values at Chebyshev points).
> > Just took a quick look, which is probably all I'll get to for a few days
> > I'm going out of town tomorrow. Anyway, the Chebyshev points there are
> > II, which should probably be distinguished from type I (and III & IV). I
> > also had the impression that the base class could have a few more
> > and NotImplemented bits. The Polynomial class is implemented as a
> > it might even make sense to use multiple inheritance (horrors) to get
> > specific polynomial types, but anyway it caught my attention and that
> > of the design might be worth spending some time thinking about. It also
> > might be worth distinguishing series as a separate base because series do
> > admit the division operators //, %, and divmod. Scalar
> > multiplication/division (__truedivision__) should also be built in. I've
> > also been using "from __future__ import division" up at the top to be
> > ready. For a series basis I was thinking of using what I've got for
> > Chebyshev but with a bunch of the __foo__ functions raising the
> > NotImplementedError. I've also got a single function for importing the
> > coefficient arrays and doing the type conversions/checking. It's worth
> > that one way for all the implementations as it makes it easier to
> > things.
> The polynomial class as a wrapper was a design decision. My reasoning
> was that certain data - roots, integration schemes, weights for
> barycentric interpolation, and so on - are associated with the basis
> rather than any particular polynomial. The various algorithms are also
> associated with the basis, of course (or rather the family of bases).
> So that leaves little in the way of code to be attached to the
> polynomials themselves; basically just adapter code, as you noted.
> This also allows users to stick to working with plain arrays of
> coefficients, as with chebint/chebder/etc. if they prefer. But the
> design is very much open for discussion.
> I agree, there are some good reasons to implement a class for graded
> polynomial bases in which the ith polynomial has degree i. One would
> presumably implement a further class for polynomial bases based on
> orthogonal families specified in terms of recurrence relations.
> Division operators make sense to implement, yes; there are sensible
> notions of division even for polynomials in the Lagrange or Bernstein
> bases. I just hadn't included those functions yet.
> > I've attached the low->high version of the chebyshev.py file just for
> > further reference. The Chebyshev class is at the end.
> Thanks, I'll take a look at it.
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
In : def cat() : print 'meow'
In : def dog() : print 'woof'
In : def pet_factory(f) :
....: class pet :
....: def talk(self) :
....: print f()
....: return pet
In : DogClass = pet_factory(dog)
In : mydog = DogClass()
In : mydog.talk()
In : CatClass = pet_factory(cat)
In : mycat = CatClass()
In : mycat.talk()
I'm not sure why the None return is printing, but that is the general idea.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev