[Numpy-discussion] Polynomials

[Ralf Gommers]

On Wed, Aug 25, 2010 at 11:44 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Wed, Aug 25, 2010 at 8:00 AM, Ralf Gommers <ralf.gommers at googlemail.com
> > wrote:
>
>>
>>
>> On Tue, Aug 24, 2010 at 10:58 PM, Travis Oliphant <oliphant at enthought.com
>> > wrote:
>>
>>>
>>> On Aug 23, 2010, at 10:30 PM, Charles R Harris wrote:
>>>
>>> > Hi All,
>>> >
>>> > I've gone ahead and implemented the Laguerre and Hermite (H and He)
>>> polynomials, but at this point I'm loath to add them to numpy as the
>>> polynomial space is getting crowded. Scipy looks like a better spot to put
>>> these but there is already the orthogonal module there. OTOH, the orthogonal
>>> module uses poly1d for the representation and that is numerical poison. The
>>> versions I have use the direct series representations in the given basis for
>>> +, -, x,  /, integration, and differentiation as well as doing direct
>>> conversions between domains and basis without going through ordinary power
>>> series, so that is a plus. They are also usable with mpmath for extended
>>> precision but at the price of sticking to python for the implementation, so
>>> they could be speeded up by restricting to doubles and complex. They don't
>>> supply the points and weights for Gauss integration, I tend to think those
>>> things belong under integration, but they could be included.
>>>
>>>
>>> Don't let the orthogonal module stop you from adding the polynomials to
>>> SciPy.   They would fit very nicely.     It would be nice to deprecate the
>>> current orthogonal polynomials over time as more numerically accurate
>>> implementations of them were included.
>>>
>>> You could put them in a module like:
>>>
>>> scipy.special.ortho
>>>
>>> or another name.   You could even replace the laguerre and hermite
>>> functions in special.orthogonal assuming the behaviors are similar.  But, to
>>> be safe, it would probably be best to put them in a different module and
>>> deprecate the old names.
>>>
>>> Is your implementation along the same lines as the Polynomial and
>> Chebyshev classes? In that case I would find it odd to split them between
>> numpy and scipy, and perhaps a little arbitrary to have Chebyshev in numpy
>> while Laguerre/Hermite (and possibly others in the future?) go into scipy.
>> And a practical concern may be that if you happen to find bugs or want to
>> make incompatible changes you have to deal with two release cycles.
>>
>>
> Yes. It turns out that all that is needed for the arithmetic is a
> multiply-by-x function which comes from the recursion relationship, and all
> that is needed for the conversions between types is the evaluation function,
> which also comes from the recursion relationship. Which leaves
> integration/differentiation as the difficult bits. Although I could also
> implement those using the recursion relationship that doesn't seem the best
> way to go, especially where simpler relationships are available. But maybe I
> will go that way just for simplicity...
>
> Another option to consider would be to stick the low-level functions in a
>> separate namespace, and just have the main classes in numpy.polynomial. Then
>> your concern about the crowded namespace is gone, and you could add your new
>> code to numpy.
>>
>>
> I was mostly concerned about the amount of code, although most of the space
> is taken up by comments, the code itself tends to be short. The comments are
> repetitious and mostly consist of cut-and-paste with name substitutions.
>
> Looking at chebyshev.py, it doesn't contain all that much actual code. And
I can only see the extensive docstrings as a plus, not as a reason to move
things over to scipy.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100826/067ca27e/attachment.html>