[SciPy-dev] Inheritance from poly1d (orthogonal.py)
Fri Jan 16 03:01:03 CST 2009
On Wed, Jan 14, 2009 at 1:45 PM, Tom Grydeland <firstname.lastname@example.org> wrote:
> Hello, developers.
> In reference to the ticket I just submitted:
> I think the problem is with the class 'poly1d' in
> numpy.lib.polynomial. Several of the methods of this class (such as
> __mul__, __rmul__, integ, deriv) refer explicitly to 'poly1d' instead
> of self's class.
I've looked into this, and while I have a few possible solutions, I am
not entirely decided on which is the correct one, perhaps because of
my lack of experience with orthogonal polynomials.
I know how to rewrite the numpy.poly1d class so that objects of
derived classes also produce derived-class objects when they are
multiplied with a scalar, differentiated, integrated etc. I do not
know that this is the right approach, however. Although the product
of an orthogonal polynomial and a scalar is another orthogonal
polynomial, the same is not true for polynomials resulting from
differentiation, integration, polynomial division etc. In short, it
should probably be up to a derived class to decide which, if any, of
these operations also result in an object of the derived class.
I also know how to rewrite particular methods of the
orthogonal.orthopoly1d class to have them produce objects of the
appropriate class, but I suspect that this also runs the risk of
producing orthogonal polynomials in inappropriate ways.
I suspect the correct way to deal with this is to explicitly create
orthopoly1d objects instead of the poly1d objects that arise from
statements like "base * factor" in orthogonal.py. I will be happy to
implement this, but somebody who understands orthogonal polynomials
(and their scipy implementation) better than me must tell me which of
their properties (e.g., weight function, roots and weights) are
preserved, and how they change when they are not. The answer to this
question determines how the changes must be made.
So, is somebody up to explaining this to me?
> In the same vein, I expect that __repr__ should use self's class
> instead of 'poly1d'.
This probably still holds true.
More information about the Scipy-dev