[Numpy-discussion] Seeking advice on crowded namespace.
Charles R Harris
charlesr.harris@gmail....
Wed Aug 18 12:38:34 CDT 2010
On Wed, Aug 18, 2010 at 11:27 AM, <josef.pktd@gmail.com> wrote:
> On Wed, Aug 18, 2010 at 12:36 PM, Charles R Harris
> <charlesr.harris@gmail.com> wrote:
> >
> >
> > On Wed, Aug 18, 2010 at 10:02 AM, Bruce Southey <bsouthey@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@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.
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100818/c4005cc1/attachment.html
More information about the NumPy-Discussion
mailing list