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

Charles R Harris charlesr.harris@gmail....
Fri Oct 9 03:01:39 CDT 2009


On Thu, Oct 8, 2009 at 1:03 PM, Anne Archibald <peridot.faceted@gmail.com>wrote:

> 2009/10/8 Charles R Harris <charlesr.harris@gmail.com>:
> > Hi Anne,
> >
> > On Thu, Oct 8, 2009 at 9:37 AM, Anne Archibald <
> peridot.faceted@gmail.com>
> > wrote:
> >>
> >> 2009/10/7 David Goldsmith <d.l.goldsmith@gmail.com>:
> >> > 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
> as
> > I'm going out of town tomorrow. Anyway, the Chebyshev points there are
> type
> > 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
> functions
> > and NotImplemented bits. The Polynomial class is implemented as a
> wrapper,
> > it might even make sense to use multiple inheritance (horrors) to get
> > specific polynomial types, but anyway it caught my attention and that
> part
> > 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
> py3k
> > 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
> doing
> > that one way for all the implementations as it makes it easier to
> fix/extend
> > 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
example

In [3]: def cat() : print 'meow'
   ...:

In [4]: def dog() : print 'woof'
   ...:

In [31]: def pet_factory(f) :
   ....:     class pet :
   ....:         def talk(self) :
   ....:             print f()
   ....:     return pet
   ....:

In [32]: DogClass = pet_factory(dog)

In [33]: mydog = DogClass()

In [34]: mydog.talk()
woof
None

In [35]: CatClass = pet_factory(cat)

In [36]: mycat = CatClass()

In [37]: mycat.talk()
meow
None

I'm not sure why the None return is printing, but that is the general idea.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091009/83787f28/attachment.html 


More information about the Scipy-dev mailing list