[Numpy-discussion] numpy migration

[Timothy Hochberg]

On 4/23/07, Duncan Smith <buzzard at urubu.freeserve.co.uk> wrote:
>
> Hello,
>      Since moving to numpy I've had a few problems with my existing
> code.  It basically revolves around the numpy scalar types. e.g.
>
> ------------------------------------------------
>
> >>> import Numeric as N
> >>> a = N.array([[0,1],[2,3]])
> >>> a
>
> array([[0, 1],
>        [2, 3]])
>
> >>> i = a[0,0]
> >>> 1/i
>
>
> Traceback (most recent call last):
>   File "<pyshell#30>", line 1, in -toplevel-
>     1/i
> ZeroDivisionError: integer division or modulo by zero
>
> >>> b = a * 1.5
> >>> b
>
> array([[ 0. ,  1.5],
>        [ 3. ,  4.5]])
>
> >>> N.floor(b)
>
> array([[ 0.,  1.],
>        [ 3.,  4.]])
>
> >>> ================================ RESTART
>
> ================================
>
> >>> import numpy as N
> >>> a = N.array([[0,1],[2,3]])
> >>> a
>
> array([[0, 1],
>        [2, 3]])
>
> >>> i = a[0,0]
> >>> 1/i
>
> 0


You should be getting a warning here. Did one disappear in the cut and
paste? Or are you using a nonstandard shell that eats warnings? Or an old
version of numpy?

In any event if you want an error rather than a warning for zero division,
use:

>>> 1/i
Warning: divide by zero encountered in long_scalars
0
SyntaxError: invalid syntax
>>> N.seterr(divide='raise')
{'over': 'print', 'divide': 'print', 'invalid': 'print', 'under': 'ignore'}
>>> 1/i
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FloatingPointError: divide by zero encountered in long_scalars

Although I'm not sure why that's a floating point error.

>>> b = a * 1.5
> >>> b
>
> array([[ 0. ,  1.5],
>        [ 3. ,  4.5]])
>
> >>> N.floor(b)
>
> array([[ 0.,  1.],
>        [ 3.,  4.]])
>
> >>> a = N.array([[0,1],[2,3]], dtype='O')
> >>> a
>
> array([[0, 1],
>        [2, 3]], dtype=object)
>
> >>> i = a[0,0]
> >>> 1/i
>
>
> Traceback (most recent call last):
>   File "<pyshell#45>", line 1, in -toplevel-
>     1/i
> ZeroDivisionError: integer division or modulo by zero


Right -- for objects, all of the operations get delegated to the Python
object in question and this is the behaviour of Python ints.


>>> b = a * 1.5
> >>> b
>
> array([[0.0, 1.5],
>        [3.0, 4.5]], dtype=object)
>
> >>> N.floor(b)
>
>
> Traceback (most recent call last):
>   File "<pyshell#48>", line 1, in -toplevel-
>     N.floor(b)
> AttributeError: 'float' object has no attribute 'floor'
>
> >>>


I'm not sure what you expect here; for object arrays numpy simply delegats
everything to the corresponding object. If you want something that supports
floor, you should be using a numerical array, not an object array.


----------------------------------------------
>
> An additional problem involves classes that have e.g. __rmul__ methods
> defined and are sufficiently similar to numpy arrays that my classes'
> __rmul__ methods are not invoked when using numpy scalars.



Try adding "__array_priority__ = 10" or somesuch to your classes. This
should tell numpy to back off and let your methods go first when doing mixed
operations. Searching for "__array_priority__" will probably turn up some
examples.

Using the 'O' dtype gives me Python types that raise zero division
> errors appropriately (for my code) and the desired calls to e.g.
> __rmul__ methods, but reduced functionality in other repects.


Right, don't do that.

I might (I hope) be missing something obvious; but it seems like, to be
> safe, I'm going to have to do a lot of explicit conversions to Python
> types (or abandon catching zero division errors, and documenting some of
> my classes to highlight that whether scalar * a equals a * scalar
> depends on whether a.__rmul__ is called, which depends on the type of
> scalar).
>
> I suppose I might get round both issues by subclassing existing numpy
> dtypes.  Any ideas?  Cheers.  TIA.


I think you should be able to do everything you need, by using seterr at
startup to make numpy picky about division errors and then using array
priority to make your methods have precedence over numpy's.

 regards,

-tim

Duncan
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 

//=][=\\

tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070424/d0f1465c/attachment.html>