[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)
Tue Oct 6 13:59:00 CDT 2009
Personally, I'd like to see NumPy "go back to" being the namespace for
ndarray and broadcasting, plus such objects' "most immediately necessary
and/or useful" accoutrement; of course, reaching an objective - or even a
consensus - definition of "most immediately necessary and/or useful" is
probably impossible, but IMO neither financial functions nor a polynomial
class qualify. Certainly, it would be optimal if one didn't need to install
the whole SciPy package to use a polynomial object (or _any_ of SciPy's
distinct modules, for that matter) but even if/while that's not possible,
I'm still "+1" for putting these things in SciPy, not NumPy.
On Tue, Oct 6, 2009 at 11:29 AM, Pauli Virtanen <email@example.com> wrote:
> ti, 2009-10-06 kello 12:11 -0600, Charles R Harris kirjoitti:
> > The features in chebyshev are pretty much the same as poly1d. You can
> > look, I posted the source on the numpy list. I want the class in numpy
> > because chebyshev support is pretty much essential to numerical work,
> > right up there with power series, and some of the existing/proposed
> > functions in scipy could make use of it.
> This would also work if it was in Scipy, IMHO. But I guess that if we
> have financial functions in Numpy, maybe there's room for more...
> > As Anne pointed out, the existing interface to the scipy chebyshev
> > functions is useless because the result is returned as a polynomial.
> Yes, also our documentation warns that the current interface is useless.
> > A second question is how much of this has to do with
> > scipy.special.
> > Quite often, one just needs values of orthogonal polynomials
> > at certain
> > points, and it could be useful to have separate fast ufuncs
> > for
> > computing these, rather than having to construct a bulky class
> > instance
> > first.
> > The class isn't bulky. The module is ~1400 lines, but most of that is
> > documentation. If you want millions of points using standard c types,
> > then a fast routine is essential.
> Yeah, Python overhead is the bulky thing, which is why we might want to
> have fast routines in addition to the ones returning class instances.
> A suitable base class or a more robust polynomial representation could
> be useful for the class-based interface, and yes, is a good idea in
> Scipy-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev