On Wed, Aug 18, 2010 at 1:27 PM, <josef.p...@gmail.com> wrote: > On Wed, Aug 18, 2010 at 12:36 PM, Charles R Harris > <charlesr.har...@gmail.com> wrote: >> >> >> On Wed, Aug 18, 2010 at 10:02 AM, Bruce Southey <bsout...@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 <bsout...@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@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion