[Numpy-discussion] Seeking advice on crowded namespace.

[josef.pktd at gmail.com]

On Wed, Aug 18, 2010 at 1:27 PM,  <josef.pktd at gmail.com> wrote:
> On Wed, Aug 18, 2010 at 12:36 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
>>
>>
>> On Wed, Aug 18, 2010 at 10:02 AM, Bruce Southey <bsouthey at 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 at 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
>
> e.g.
> 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)

just checking

>>> from numpy.polynomial import chebvander, chebfit
>>> x = chebvander(np.arange(20),3)
>>> y = x.sum(1) + 0.1*np.random.randn(x.shape[0])
>>> chebfit(np.arange(20), y, 3)
array([ 1.06500672,  0.96512466,  1.00266968,  0.9999477 ])

>>> from scikits.statsmodels import OLS
>>> res = OLS(y, x).fit()
>>> res.params
array([ 1.06500672,  0.96512466,  1.00266968,  0.9999477 ])
>>> res.bse
array([  1.14104979e-01,   5.24951183e-02,   3.25000334e-03,
         5.61553371e-05])
>>> res.t()
array([  9.33356923e+00,   1.83850363e+01,   3.08513430e+02,
         1.78068150e+04])

Josef

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