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. Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
