Difference between polynomial.trimcoef and trimseq
Is the only difference that which is in the Notes of trimseq: "Do [sic?] not lose the type info if the sequence contains unknown objects"? DG
On Sat, Jan 23, 2010 at 8:52 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
Is the only difference that which is in the Notes of trimseq: "Do [sic?] not lose the type info if the sequence contains unknown objects"?
trimseq works on sequence types and doesn't attempt to turn them into ndarrays, so does less work than trimcoef. trimseq is also used in as_series where trimcoef can't be used because the latter calls as_series itself to convert its arguments to ndarrays. I admit the distinction is not obvious at first glance. Chuck
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.) DG 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? On Sat, Jan 23, 2010 at 10:00 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Jan 23, 2010 at 8:52 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
Is the only difference that which is in the Notes of trimseq: "Do [sic?] not lose the type info if the sequence contains unknown objects"?
trimseq works on sequence types and doesn't attempt to turn them into ndarrays, so does less work than trimcoef. trimseq is also used in as_series where trimcoef can't be used because the latter calls as_series itself to convert its arguments to ndarrays. I admit the distinction is not obvious at first glance.
Chuck
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith <d.l.goldsmith@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 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. Multiplication by x should be sufficient for most things, in particular evaluation and conversion to/from other series. Apart from that, I think Legendre polynomials would fit in well. There was a request for Hermite polynomials, 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. Chuck
2010/1/24 David Goldsmith <d.l.goldsmith@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; 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. Anne
fromCharles R Harris <charlesr.harris@gmail.com> On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith <d.l.goldsmith@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?
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?
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,
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
Hermite requester: if you're reading this, did you already "roll your own"? 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@gmail.com>wrote:
2010/1/24 David Goldsmith <d.l.goldsmith@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.
Great, I'll give it a look-see! :-) DG
Anne _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, Jan 24, 2010 at 2:09 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
from Charles R Harris <charlesr.harris@gmail.com>
On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith <d.l.goldsmith@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@gmail.com> wrote:
2010/1/24 David Goldsmith <d.l.goldsmith@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
On Sun, Jan 24, 2010 at 1:10 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Sun, Jan 24, 2010 at 2:09 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
from Charles R Harris <charlesr.harris@gmail.com>
On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith < d.l.goldsmith@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.
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?) DG
Chuck
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, Jan 24, 2010 at 3:04 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
On Sun, Jan 24, 2010 at 1:10 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sun, Jan 24, 2010 at 2:09 AM, David Goldsmith <d.l.goldsmith@gmail.com
wrote:
from Charles R Harris <charlesr.harris@gmail.com>
On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith < d.l.goldsmith@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
On Sun, Jan 24, 2010 at 2:50 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Sun, Jan 24, 2010 at 3:04 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
On Sun, Jan 24, 2010 at 1:10 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sun, Jan 24, 2010 at 2:09 AM, David Goldsmith < d.l.goldsmith@gmail.com> wrote:
from Charles R Harris <charlesr.harris@gmail.com>
On Sat, Jan 23, 2010 at 11:08 PM, David Goldsmith < d.l.goldsmith@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.
Gotchya, sounds reasonable. DG
Chuck
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sun, Jan 24, 2010 at 12:44 AM, Anne Archibald <peridot.faceted@gmail.com>wrote:
2010/1/24 David Goldsmith <d.l.goldsmith@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; if you choose the right evaluation points they are competitive with Chebyshev polynomials for many purposes, and they can do other things as well.
Speaking of polynomials by value, I have some (cython) routines for barycentric interpolation of trigonometric polynomials I wanted to add to your barycentric work but it seemed that some reorganization of the interpolation folder with maybe some renaming might be in order. I was thinking of a separate barycentric folder. Also, I think the name polyint could maybe be changed to something more suggestive of the contents. Chuck
participants (3)
-
Anne Archibald -
Charles R Harris -
David Goldsmith