[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)
Wed Oct 14 00:03:35 CDT 2009
2009/10/13 Charles R Harris <email@example.com>:
> On Tue, Oct 13, 2009 at 7:24 PM, Anne Archibald <firstname.lastname@example.org>
>> specifying the interval. And if people do want to specify the
>> interval, using a basis object makes it much easier to avoid
>> forgetting it and getting nonsensical results (or worse, sensible
>> results until you try a different interval).
> That is because they are low level building blocks, they should have the
> absolute minimum of crud stuck on, and that means the interval is [-1, 1].
> If you need more, that is what a class is for. That how low level things
> should work, small functions doing the minimum amount provide the most
> flexibility. The programmer should be handed enough rope to hang themselves
> at that level if they so choose. That's why folks use C and not Pascal.
Well, the glib answer would be that we're using python, so we should
choose a pythonic way of doing things. But clearly having the
low-level functions is important to some potential users - you and
Robert Kern, plus surely more other people - so where possible the
code should accommodate the as-low-level-as-possible approach.
How's this for a compromise? The high-level class interface has a
Polynomial object and various Basis subclasses. For representations
where having a featureful Basis object is important, the
implementation should just write one, inheriting as appropriate. For
representations that don't need this extra stuff, people can just
write a collection of functions acting on coefficient arrays (as you
did for the Chebyshev polynomials) and create a basis object using
ChebyshevBasis = generate_basis("ChebyshevBasis", mul=chebmul, ...)
I have a demonstration implementation in git now.
>> I'm not sure I understand this - consistency with what? It is only
>> scalars you can reasonably add to coefficient arrays by wrapping in a
>> list; other coefficient arrays must be the same length as the other
>> (array) summand or they will fail. And scalars work just as well
>> without wrapping in a list, so why do it?
> Scalars should work with and without wrapping, no? But I think using an
> empty list for what is actually a polynomial all of whose coefficients are
> zero is mixing apples and oranges.
No, I don't think wrapping is a sensible thing to do to scalars. I
think it's a bizarre quirk (in this instance) that numpy broadcasting
allows you to add a one-element array to a three-element array - and
in fact it's wrong! In the power basis, [1,2] is the polynomial 1+2*X.
[1,2]+ = [2,3] is the polynomial 2+3*X - not 1+2*X + 1. So you just
plain can't (correctly) add scalars to coefficient arrays, with the
sole exception of zero.
As for the conceptual representation, every polynomial is implicitly
extended by zeros, and every nonzero polynomial normally stops after
the last nonzero entry. Using the array of shape (0,) follows these
rules exactly, while using the array of shape (1,) containing zero
breaks the second, albeit in a not-very-important way (since trailing
zeros can occur in non-normalized polynomials).
More information about the Scipy-dev