[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)
Fri Oct 9 11:41:50 CDT 2009
On Fri, Oct 9, 2009 at 1:28 AM, Sebastian Walter <email@example.com
> 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). ;-)
> On Fri, Oct 9, 2009 at 10:01 AM, Charles R Harris
> <firstname.lastname@example.org> wrote:
> > On Thu, Oct 8, 2009 at 1:03 PM, Anne Archibald <
> > wrote:
> >> 2009/10/8 Charles R Harris <email@example.com>:
> >> > Hi Anne,
> >> >
> >> > On Thu, Oct 8, 2009 at 9:37 AM, Anne Archibald
> >> > <firstname.lastname@example.org>
> >> > wrote:
> >> >>
> >> >> 2009/10/7 David Goldsmith <email@example.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
> >> > 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).
> >> > 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
> >> > 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.
> >> > 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
> > class template replicated with different values for, i.e.,
> > division, etc. One way to do that in python is with a class factory. For
> > example
> > 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()
> > woof
> > None
> > In : CatClass = pet_factory(cat)
> > In : mycat = CatClass()
> > In : mycat.talk()
> > meow
> > None
> > I'm not sure why the None return is printing, but that is the general
> > Chuck
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipyfirstname.lastname@example.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> Scipy-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev