[SciPy-dev] Difference between polynomial.trimcoef and trimseq

[Charles R Harris]

On Sun, Jan 24, 2010 at 3:04 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> On Sun, Jan 24, 2010 at 1:10 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>> On Sun, Jan 24, 2010 at 2:09 AM, David Goldsmith <d.l.goldsmith at gmail.com
>> > wrote:
>>
>>> from
>>> Charles R Harris <charlesr.harris at gmail.com>
>>>
>>> On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith <
>>> d.l.goldsmith at gmail.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
>>> difficult.
>>>
>>> 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
> functions.
>
>

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
desirable.

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