[Numpy-discussion] Seeking advice on crowded namespace.

[Bruce Southey]

  On 08/17/2010 04:34 PM, Charles R Harris wrote:
>
>
> On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <bsouthey@gmail.com 
> <mailto: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
>
> p.convert(kind=Chebyshev)
>
> 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.
>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thanks,
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.

Bruce




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100818/5ff6d725/attachment-0001.html