[Numpy-discussion] Unpleasant behavior with poly1d and numpy scalar multiplication
Charles R Harris
charlesr.harris@gmail....
Sat Feb 13 12:00:51 CST 2010
On Sat, Feb 13, 2010 at 10:24 AM, Charles R Harris <
charlesr.harris@gmail.com> wrote:
>
>
> On Sat, Feb 13, 2010 at 10:04 AM, Fernando Perez <fperez.net@gmail.com>wrote:
>
>> On Sat, Feb 13, 2010 at 10:34 AM, Charles R Harris
>> <charlesr.harris@gmail.com> wrote:
>> > The new polynomials don't have that problem.
>> >
>> > In [1]: from numpy.polynomial import Polynomial as Poly
>> >
>> > In [2]: p = Poly([1,2])
>>
>> Aha, great! Many thanks, I can tell my students this, and just show
>> them the caveat of calling float(x) on any scalar they want to use
>> with the 'old' ones for now.
>>
>> I remember being excited about your work on the new Polys, but since
>> I'm teaching with stock 1.3, I hadn't found them recently and just
>> forgot about them. Excellent.
>>
>> One minor suggestion: I think it would be useful to have the new
>> polys have some form of pretty-printing like the old ones. It is
>> actually useful when working, to verify what one has at hand, to see
>> an expanded printout like the old ones do:
>>
>>
> I thought about that, but decided it was best left to a derived class, say
> PrettyPoly ;) Overriding __repr__ and __str__ is an example where
> inheritance makes sense.
>
>
Hmm, and on testing it looks like maybe "isinstance" should be replaced with
"type(s) is x" to avoid the left-right confusion when mixing derived classes
with the base class. Binary operators play havoc with inheritance.
<snip>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100213/02ae165f/attachment.html
More information about the NumPy-Discussion
mailing list