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

[Sebastian Walter]

def cat() : print 'meow'
should be
def cat(): return 'meow'

that should get rid of the None


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
>
>