[Numpy-discussion] Seeking advice on crowded namespace.

Charles R Harris charlesr.harris@gmail....
Tue Aug 17 16:34:31 CDT 2010

On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <bsouthey@gmail.com> wrote:

>  On 08/16/2010 10:00 PM, Charles R Harris wrote:
> > Hi All,
> >
> > I just added support for Legendre polynomials to numpy and I think the
> > numpy.polynomial name space is getting a bit crowded. Since most of
> > the current functions in that namespace are just used to implement the
> > Polynomial, Chebyshev, and Legendre classes I'm thinking of only
> > importing those classes by default and leaving the other functions to
> > explicit imports. Of course I will have to fix the examples and maybe
> > some other users will be inconvenienced by the change. But with 2.0.0
> > in the works this might be a good time to do this. Thoughts?
> >
> > Chuck
> While I don't know a lot about this so things will be easily off base.
> In looking at the names, I did see many names that seem identical except
> that these work just with one type of polynomial.
> Obviously cheb2poly and poly2cheb are the conversion between the
> polynomial and Chebyshev types - similarly leg2poly and poly2leg for the
> polynomial and Legendre classes. But none between Chebyshev and Legendre
> classes. Would it make more sense to create a single conversion function
> to change one type into another instead of the current 6 possibilities?
The class types can be converted to each other, with an optional change of
domain, using the convert method, i.e., if p is an instance of Legendre


will do the conversion to a Chebyshev series.. The classes don't actually
use the *2* functions, oddly enough ;)

> Similarily there are obviously a very similar functions that just work
> with one polynomial type so the functionality is duplicated across each
> class that could be a single function each:
> chebadd    legadd    polyadd
> chebder    legder    polyder
> chebdiv    legdiv    polydiv
> chebdomain    legdomain    polydomain
> chebfit    legfit    polyfit
> chebfromroots    legfromroots    polyfromroots
> chebint    legint    polyint
> chebline    legline    polyline
> chebmul    legmul    polymul
> chebmulx    legmulx    polymulx
> chebone    legone    polyone
> chebroots    legroots    polyroots
> chebsub    legsub    polysub
> chebtrim    legtrim    polytrim
> chebval    legval    polyval
> chebvander    legvander    polyvander
> chebx    legx    polyx
> chebzero    legzero    polyzero
> However, I doubt that is worth the work if the overall amount of code is
> not reduced. For example, if you create a overall function that just
> calls the appropriate add function for that type of polynomial then I do
> not see any advantage in doing so just to reduce the namespace.
> If you can argue that is very beneficial to the user of polynomial
> functions then that could put a different spin on doing that.
> While I would have to check more carefully (as I don't have time now),
> aren't chebadd, legadd and polyadd essentially the same function?
> That is, can you send a Legendre polynomial to the same Chebysnev
> function and get the same answer back?
> If so then these functions should be collapsed into one for numpy 2.0.
Yeah, the add and subtract functions are all the same along with the *trim
functions. These things are all accessable through the classes ustng +/- and
the trim and truncate methods. Which is why for normal work I think the
classes are the way to go, the functions are just for implementing the
classes and available in case someone wants to roll their own.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100817/25d8824a/attachment.html 

More information about the NumPy-Discussion mailing list