[SciPy-dev] Difference between polynomial.trimcoef and trimseq
Sun Jan 24 16:04:45 CST 2010
On Sun, Jan 24, 2010 at 1:10 PM, Charles R Harris <firstname.lastname@example.org
> 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
> 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
> 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
> 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?)
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev