[Numpy-discussion] Seeking advice on crowded namespace.
Wed Aug 18 11:02:33 CDT 2010
On 08/17/2010 04:34 PM, Charles R Harris wrote:
> On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <firstname.lastname@example.org
> <mailto:email@example.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
> > some other users will be inconvenienced by the change. But with
> > 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
> 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
> classes. Would it make more sense to create a single conversion
> to change one type into another instead of the current 6
> 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
> 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.
> NumPy-Discussion mailing list
Now that I understand things a little better, I would agree with your
original suggestion is to only import the class and leave the other
functions as explicit imports.
But I would go further and say that these other functions should be
depreciated and removed especially if polynomial users consider classes
should be used. If someone wants to roll their own, then they probably
know enough to do so without needing these functions. Also, one of the
things I noticed is that there is no checks on these other functions for
the type of polynomial such that any input other than the correct input
could be used. Sure user beware but at least with a class the correct
input should be used.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion