[Numpy-discussion] Seeking advice on crowded namespace.
Charles R Harris
charlesr.harris@gmail....
Wed Aug 18 11:36:22 CDT 2010
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.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100818/5f3c9df0/attachment.html
More information about the NumPy-Discussion
mailing list