[SciPy-dev] Difference between polynomial.trimcoef and trimseq
Charles R Harris
Sun Jan 24 16:50:32 CST 2010
On Sun, Jan 24, 2010 at 3:04 PM, David Goldsmith <email@example.com>wrote:
> On Sun, Jan 24, 2010 at 1:10 PM, Charles R Harris <
> firstname.lastname@example.org> wrote:
>> On Sun, Jan 24, 2010 at 2:09 AM, David Goldsmith <email@example.com
>> > wrote:
>>> Charles R Harris <firstname.lastname@example.org>
>>> On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith <
>>> email@example.com> wrote:
>>>> Do you think a typical user would ever use both? (Or is this an
>>>> efficiency that most can live w/out? I'm just curious how much we should
>>>> "explain ourselves" in their docstrings.)
>>>> > Hard to say ;) I wrote the docstrings for the helper funtions
>>> And in this case the "helper function" is the trimseq, correct?
>>> Yes, and pretty much the rest of the functions in polyutils, but trimseq
>> is sort of lower level than the others.
> OK, thanks for the clarification.
>> > mostly for my own use and think of those helper functions as private.
>>> They are in the standard import just in case anyone wants
>>> > to do their own stuff.
>>>> PS: If I were to use chebyshev as my "template," what would you say is
>>>> the next most useful/algorithmically-studied polynomial basis to implement?
>>> > The power/Chebyshev series have the special property that it is easy
>>> to multiply/divide them, so the template needs to lose a
>>> > few features to be useful for functions where that is far more
>>> Yeah, that's what I meant by "algorithmically-studied": AFAYK,
>>> numericists haven't derived/discovered nearly as efficient "tricks" for
>>> operating on the other orthos/classes as they have for the standard and
>>> Chebyshev bases? BTW: on the subject of "numerical tricks," are there such
>>> for trigonometric polynomials?
>> Trigonometric polynomials could pretty much follow the Chebyshev pattern,
>> they are essentially the z-series. The trick is to decide how to represent
>> the coefficients. The complex exponential form is easy to work with but not
>> so easy to enter as data, the sin/cos version is easier in that respect but
>> effectively requires two sets of coefficients.
> Sounds like the ideal sit. would be to implement both w/ go between
Yeah, that could be done. The template approach is a bit of a stunt for just
the two polynomial types, but maybe it will justify itself if the
trigonometric polynomials are added. Hmm....
> The main virtue of such a trigonometric series relative to using an fft is
>> that the sample/interpolation points can be more general.
> That, and pedagogical purposes (trigonometric poly's are still taught in
> various contexts, aren't they? Plus instructors might like to have both
> implemented to illustrate the relationships and relative advantages. You
> can see where I'm coming from: part of what I consider to be my charge is to
> assure some suitability of NumPy/SciPy as an instructional tool, not just a
> research/professional tool.)
>> The drawback is that the fft is much faster for large degree.
> Of course, thus the name. ;-)
>> Polynomials by value would be a valuable addition. But I'm thinking the
>> framework should specific to that problem and not try to be more general.
>> It's a tradeoff between simplicity and generality and I incline towards
>> simplicity here along with numerical speed.
> Is this a case where that relationship doesn't lend itself to
> class/subclass? (E.g., because the implementation details are vastly
> different to achieve the speed gains of the specialized?)
Looking back on the discussion, I think we were shooting for too much
generality in a single implementation. An more productive approach might be
to treat each area -- graded polynomials, lagrange, Bernstein, and B-splines
-- in a way most appropriate to each. The experience gained in such an
approach could help us if at some point a generalized framework looks
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev