Charles R Harris
Wed Aug 25 10:44:52 CDT 2010
On Wed, Aug 25, 2010 at 8:00 AM, Ralf Gommers
> On Tue, Aug 24, 2010 at 10:58 PM, Travis Oliphant <email@example.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:
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion