On 08/17/2010 04:34 PM, Charles R Harris wrote:
On Tue, Aug 17, 2010 at 2:43 PM, Bruce Southey <[email protected]
<mailto:[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.
Chuck
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thanks,
Now that I understand things a little better, I would agree with your
original suggestion is to only import the class and leave the other
functions as explicit imports.
But I would go further and say that these other functions should be
depreciated and removed especially if polynomial users consider classes
should be used. If someone wants to roll their own, then they probably
know enough to do so without needing these functions. Also, one of the
things I noticed is that there is no checks on these other functions for
the type of polynomial such that any input other than the correct input
could be used. Sure user beware but at least with a class the correct
input should be used.
Bruce
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
