[Numpy-discussion] Seeking advice on crowded namespace.
Charles R Harris
Wed Aug 18 12:38:34 CDT 2010
On Wed, Aug 18, 2010 at 11:27 AM, <email@example.com> wrote:
> On Wed, Aug 18, 2010 at 12:36 PM, Charles R Harris
> <firstname.lastname@example.org> wrote:
> > On Wed, Aug 18, 2010 at 10:02 AM, Bruce Southey <email@example.com>
> >> On 08/17/2010 04:34 PM, Charles R Harris wrote:
> >> On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <firstname.lastname@example.org>
> >>> 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
> >>> > numpy.polynomial name space is getting a bit crowded. Since most of
> >>> > the current functions in that namespace are just used to implement
> >>> > 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
> >>> 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
> >>> polynomial and Legendre classes. But none between Chebyshev and
> >>> classes. Would it make more sense to create a single conversion
> >>> 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
> >> 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
> >> 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
> >>> not reduced. For example, if you create a overall function that just
> >>> calls the appropriate add function for that type of polynomial then I
> >>> 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
> >> functions. These things are all accessable through the classes ustng +/-
> >> 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
> > functions. The classes implement a common interface, the functions do
> > is specific to the various types of polynomial. In general it is a good
> > 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
> > cursing the SOB who buried the good stuff in a class, creating all sorts
> > inconvenient dependencies. That's my experience, anyway. I also wanted to
> > keep open the possibility of using cython to speed up specific small bits
> > 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.
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion