On Wed, Aug 18, 2010 at 11:27 AM, <[email protected]> wrote: > On Wed, Aug 18, 2010 at 12:36 PM, Charles R Harris > <[email protected]> wrote: > > > > > > On Wed, Aug 18, 2010 at 10:02 AM, Bruce Southey <[email protected]> > wrote: > >> > >> On 08/17/2010 04:34 PM, Charles R Harris wrote: > >> > >> On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <[email protected]> > 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. > > I'm sorta of thinking about adding Hermite and Laguerre polynomials. I can't quite figure how to include domains like [-inf, inf] into the way things are currently done, at least in a way that seems intuitive.
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 > > That's a thought. > (chebvander might be nicer than chebfit, because I can also calculate > the covariance matrix :) > (haven't tried it yet) > > I'd like to make getting the covariance an option but that means bypassing the version of lstsq that is in linalg. Chuck.
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
