[Numpy-discussion] chebyshev polynomials
Thu Sep 24 15:34:50 CDT 2009
to, 2009-09-24 kello 13:53 -0600, Charles R Harris kirjoitti:
> I was thinking of storing the chebyshev internally as the values at
> the chebyschev points. This makes multiplication, differentiation and
> such quite easy (resample and multiply/divide appropriatately). Its
> equivalent to working in the fourier domain for convolution and
> differentiation. The transform back and forth is likewise othogonal,
> so stable. The intepolation also becomes simple using the barycentric
Sounds like you know this stuff well :)
The internal representation of each orthogonal polynomial type can
probably be whatever works best for each case. It should be no problem
to sugar ChebyPoly up after the main work has been done.
> As a side note, should the cheby* versions of `polyval`,
> `polymul` etc. just be dropped to reduce namespace clutter?
> You can do the same things already within just class methods
> and arithmetic.
> What do you mean? The evaluation can use various stable methods
> appropriate to the chebyshev series.
This comment was just on the API -- the implementation of course should
> I have a set of functions that does the first (works on
> multidimensional arrays of coefficients, actually), but I am open to
> ideas of what such a chebyschev class with these methods should look
> like. An interval of definition should probably be part of the ctor.
Having the following features could be useful:
- __call__, .roots, .order: as in poly1d
- .data -> whatever is the internal representation
- .coef -> Chebyshev coefficients?
- .limits -> The interval
- arithmetic: chebyshev <op> chebyshev -> chebyshev
- arithmetic: scalar <op> chebyshev -> chebyshev
- arithmetic: poly1d <op> chebyshev -> chebyshev/poly1d (??)
I'm not sure what __getitem__ and __array__ ought to return.
Alternatives seem either to return the poly1d coefficients, or not to
define these methods -- otherwise there will be confusion, especially if
we want to use these in scipy.special.orthogonal.
More information about the NumPy-Discussion