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

[David Goldsmith]

On Fri, Oct 9, 2009 at 1:28 AM, Sebastian Walter <sebastian.walter at gmail.com
> wrote:

> def cat() : print 'meow'
> should be
> def cat(): return 'meow'
>
> that should get rid of the None
>

And return a really loud meow (as the cat() is def, it can't hear how loud
it is and overcompensates). ;-)

DG

>
>
> On Fri, Oct 9, 2009 at 10:01 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Thu, Oct 8, 2009 at 1:03 PM, Anne Archibald <
> peridot.faceted at gmail.com>
> > wrote:
> >>
> >> 2009/10/8 Charles R Harris <charlesr.harris at gmail.com>:
> >> > Hi Anne,
> >> >
> >> > On Thu, Oct 8, 2009 at 9:37 AM, Anne Archibald
> >> > <peridot.faceted at gmail.com>
> >> > wrote:
> >> >>
> >> >> 2009/10/7 David Goldsmith <d.l.goldsmith at 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
> >
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091009/26356999/attachment.html>