[Numpy-discussion] Seeking advice on crowded namespace.

josef.pktd@gmai... josef.pktd@gmai...
Wed Aug 18 12:27:36 CDT 2010

On Wed, Aug 18, 2010 at 12:36 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> On Wed, Aug 18, 2010 at 10:02 AM, Bruce Southey <bsouthey@gmail.com> wrote:
>> 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> 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.
> The various classes are generated from a single string template and need the
> functions. The classes implement a common interface, the functions do what
> is specific to the various types of polynomial. In general it is a good idea
> to keep the specific bits out of classes since designing *the* universal
> class is hard and anyone who wants to just borrow a bit of code will end up
> cursing the SOB who buried the good stuff in a class, creating all sorts of
> inconvenient dependencies. That's my experience, anyway. I also wanted to
> keep open the possibility of using cython to speed up specific small bits of
> the code.

I also like internal code that can be borrowed.

One possible idea if you keep extending polynomial and the number of
modules and unique names is to import the extra functions into a
common module but not into the main namespace.

e.g. poly.py
from polynomial import *
from chebyshev import *
from polyutils import *

and import only the classes into the main namespace

from np.polynomial.poly import chebvander, chebfit, polyfit

(chebvander might be nicer than chebfit, because I can also calculate
the covariance matrix :)
(haven't tried it yet)


> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list