[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)

David Goldsmith d.l.goldsmith@gmail....
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 <pav@iki.fi> wrote:

> ti, 2009-10-06 kello 12:11 -0600, Charles R Harris kirjoitti:
> [clip]
> > 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
> general.
> Cheers,
> Pauli
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091006/4205579e/attachment.html 

More information about the Scipy-dev mailing list