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

[Charles R Harris]

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.

> 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. The main virtue of such a
trigonometric series relative to using an fft is that the
sample/interpolation points can be more general. The drawback is that the
fft is much faster for large degree.


> > Multiplication by x should be sufficient for most things, in
>
> Which, in the standard basis at least, is just a prepending of a zero, of
> course...
>
>
> > particular evaluation and conversion to/from other series.
> > Apart from that, I think Legendre polynomials would fit in well. There
>
> That was my first guess as to what to do next.
>
>
> > was a request for Hermite polynomials,
>
> Hermite requester: if you're reading this, did you already "roll your own"?
>
>
> > which shouldn't be difficult in principle, but perhaps more so in
> practice because there
> > are two versions that go under that name but have different scalings. It
> is also more difficult to assign a fixed domain for them
> > because the domain essentially expands with the degree. But I don't think
> those difficulties are fundamental.
>
> No, I agree (I think): the issue is more one of "given a particular basis,
> what can one do to stay in the basis while only manipulating the
> coefficients" - if your multiplying Legendre polynomials, e.g., the natural
> default is that you want the result to also be Legendre.  If good algorithms
> for this have been worked out for standard and Cheby, but no others...well,
> at the very least, it helps me see why you stopped where you did. ;-)
>
> > Chuck
>
> On Sat, Jan 23, 2010 at 11:44 PM, Anne Archibald <
> peridot.faceted at gmail.com> wrote:
>
>> 2010/1/24 David Goldsmith <d.l.goldsmith at gmail.com>:
>>
>> > 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?
>>
>> There was extensive (and occasionally heated) discussion of other
>> polynomial representations around the time the Chebyshev routines were
>> being introduced. My point of view in that discussion was that there
>> should be a general framework for working with polynomials in many
>> representations, but the representations I thought might be worth
>> having were:
>>
>> (a) Power basis.
>> (b) Chebyshev basis.
>> (c) Bases of other families of orthogonal polynomials.
>> (d) Lagrange basis (polynomials by value).
>> (e) Spline basis.
>>
>> The need for polynomials expressed in terms of other families of
>> orthogonal polynomials is to some degree alleviated by the improved
>> orthogonal polynomial support that came in a little after the
>> discussion. Polynomials by value are a useful tool;
>
>
> This was my other leading candidate for "Next!"
>
>
>> if you choose the
>> right evaluation points they are competitive with Chebyshev
>> polynomials for many purposes, and they can do other things as well.
>> The spline basis would be nice, in that it would give people good
>> tools for manipulating functions represented by splines, but the
>> issues of numerical instability with degree raising and lowering
>> suggest to me that they're not going to be that useful as a generic
>> polynomial library.
>>
>> So I think my vote would be for polynomials by value. Not that I'm
>> unbiased! I have a mostly-functional implementation:
>> http://github.com/aarchiba/scikits.polynomial
>> I can't vouch for its consistency with the current implementations, or
>> its completeness; it's been a while since I worked on it.
>>
>
>
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.

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