[Numpy-discussion] Seeking advice on crowded namespace.
Charles R Harris
Tue Aug 17 16:34:31 CDT 2010
On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <firstname.lastname@example.org> 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...
More information about the NumPy-Discussion