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

[Charles R Harris]

On Wed, Oct 14, 2009 at 7:09 PM, Anne Archibald
<peridot.faceted at gmail.com>wrote:

> 2009/10/14 Charles R Harris <charlesr.harris at gmail.com>:
> >
> >
> > On Wed, Oct 14, 2009 at 12:43 PM, Anne Archibald <
> peridot.faceted at gmail.com>
> > wrote:
> >>
> >> Could the basis objects share code in some other way? I don't really
> >> see another good approach - for example I don't see how your
> >> loose-functions-plus-class-maker would handle the issue of power(),
> >> which is generic for some implementations but specialized in others. I
> >> expect roots() to be the same.
> >>
> >
> > I think we should look at Josef's suggestions of metaclasses also.
>
>
>
> >> Joking aside, this really is applying your technique to my preferred
> >> structure of polynomial object plus basis object. I think there's a
> >> real need for a basis object, and if you want to be able to create one
> >> simply by specifying a handful of low-level functions, this will do it
> >> for you.
> >>
> >
> > I don't like the idea of passing the basis into the instance constructor,
> I
> > think it would be preferable to pass it into the constructor of a class
> > creator. That is why Josef's suggestion of a metaclass rouses my
> curiosity.
> > Now if I can only figure out what metaclasses are...
>
> I think passing it to the constructor is kind of a side issue (as I
> said, users are never supposed to call the constructor); if I
> understand correctly, what you're objecting to is the fact that every
> polynomial has a .basis attribute that points to the basis its
> coefficients represent.
>
>
Wait a minute, let's get this straight. Users aren't supposed to use the
class object, but only instances generated from some primeval instance
created out of nothingness in the module? That sounds like a factory object,
but not of the traditional sort. Mathematicians may theoretically start with
the empty set and a couple of axioms, but most don't work that way ;) How
does repr work, since it is supposed to generate a string that can be run to
recreate the object? Doesn't it need to call the constructor? Same with
unpickling.


> Certainly every polynomial needs to know what basis it is in, and many
> users will also need to know. But it would be possible to create a
> class for every different basis and store the basis object in the
> class, so that a polynomial contains only its coefficients and a
> pointer to its class. Then you could extract a polynomial's basis by
> doing, say, mypoly.__class__.basis. Apart from the ugliness of doing
> this, I find it rather unpleasant to have potentially thousands of
> class objects floating around


Well, identifying different classes by attaching a name attribute, in this
case a basis, is how some folks identified classes back in the paleolithic
period of C++, Borland comes to mind, IIRC, they used to attach an
identifier to plain old structures too. It works, sorta, but it is just a
lightweight version of having lots of different classes.  But it does seem
to me that your contruction is oriented towards Lagrange bases and
barycentric interpolation and the desire to have it also incorporate graded
polynomial basis and such has complicated it. It would be simpler to just
build a different classes for the different sorts of polynomials.


> - remember PowerBasis(0) is different
> from PowerBasis(0.32). Also, you have to do some careful work to check
> polynomial compatibility: people can, and often will, create different
> basis objects that represent the same object. Either you need to
> implement a flyweight pattern for your basis objects (or classes -
> ugh), or you need to have a way of detecting when two polynomials with
> different classes are actually compatible (because the Basis objects
> used to manufacture the classes are equal but not the same object).
>
> How do different classes end up with the same basis. And where do all the
different
basis come from if the user doesn't generate them and call the constructor?


> It just seems simpler to me to have the basis as a full-fledged
> attribute of the polynomial class. Given that polynomial classes are
> supposed to be immutable, that means it has to be passed in the
> constructor.
>
>
I think is would be simpler to seek less generality. You have an abstract
Basis class, then a derived GradedBasis class, then a factory function to
generate a GeneratedBasis class derived from GradedBasis,  and that class
has to be instantiated somewhere. Then there is a Polynomial class that
accepts a basis (or basis class?). How is that simpler then a factory
function that just builds specific classes for specific instances of graded
polynomials out of a few defined functions and inherits only from object?
The setup you have looks a bit over designed.


> As for metaclasses, well, in older versions of python if you took an
> object's __class__ you got an object representing the object. It
> mostly bundled together a bunch of methods, most notably the
> constructor for instances. But the type of this object was always the
> same. Metaclasses let you use a different type for this object
> representing the type of an instance. For example, if you wanted every
> class someone defined to be registered in some central registry, you
> could make a metaclass that upon instantiation registered itself.


That's one example, but there are others. In any case, after doing some
reading, metaclasses don't seem to me to be the way to go.

<snip>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091014/24497791/attachment.html>