numpy migration (also posted to numpy-discussion)

Discussion in 'Python' started by Duncan Smith, Apr 23, 2007.

  1. Duncan Smith

    Duncan Smith Guest

    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
    >>> 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
    >>> 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'
    >>>

    ----------------------------------------------

    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.


    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.

    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.

    Duncan
    Duncan Smith, Apr 23, 2007
    #1
    1. Advertising

  2. Duncan Smith 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.
    >


    You will probably get more help on the numpy discussion list:




    You are encountering problems because numpy scalar types don't raise
    errors (unless you have set the appropriate hardware flag using
    numpy.seterr).

    You can get Python scalars out of NumPy arrays if you really want them
    using (for example...)

    a.item(0,0)


    >
    > 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.
    >


    Could you please post an example showing the problem?

    >
    > 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).
    >


    numpy scalars are try a lot more things before giving up on
    multiplication and letting the other class have a stab at it.

    Post your problems to the numpy discussion list for better help and more
    discussion.


    -Travis
    Travis E. Oliphant, Apr 24, 2007
    #2
    1. Advertising

  3. Duncan Smith

    Duncan Smith Guest

    Travis E. Oliphant wrote:
    > Duncan Smith 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.
    >>

    >
    > You will probably get more help on the numpy discussion list:
    >
    >
    >
    >
    > You are encountering problems because numpy scalar types don't raise
    > errors (unless you have set the appropriate hardware flag using
    > numpy.seterr).
    >


    Aha!

    > You can get Python scalars out of NumPy arrays if you really want them
    > using (for example...)
    >
    > a.item(0,0)
    >
    >
    >>
    >> 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.
    >>

    >
    > Could you please post an example showing the problem?
    >


    I'll try to post a minimal example tomorrow. But they are classes that
    have an ndarray as an attribute, and with __getitem__ and __setitem__
    methods which simply call the corresponding array methods. Maybe that's
    enough to account for the behaviour? I'll check tomorrow.

    >>
    >> 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).
    >>

    >
    > numpy scalars are try a lot more things before giving up on
    > multiplication and letting the other class have a stab at it.
    >
    > Post your problems to the numpy discussion list for better help and more
    > discussion.
    >


    Yes, I have done. But it's awaiting moderation; presumably because I
    posted using a different e-mail address than the one I registered with
    (I wasn't thinking). Thanks for the reply.

    Duncan
    Duncan Smith, Apr 24, 2007
    #3
  4. Duncan Smith

    Duncan Smith Guest

    Travis E. Oliphant wrote:
    > Duncan Smith 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.
    >>

    >
    > You will probably get more help on the numpy discussion list:
    >
    >
    >
    >
    > You are encountering problems because numpy scalar types don't raise
    > errors (unless you have set the appropriate hardware flag using
    > numpy.seterr).
    >


    Unfortunately it seems to raise a FloatingPointError.

    >>> import numpy as N
    >>> N.__version__

    '1.0.1'
    >>> a = N.array([[0,1],[2,3]])
    >>> a

    array([[0, 1],
    [2, 3]])
    >>> i = a[0,0]
    >>> 1/i

    0
    >>> N.seterr(divide='raise')

    {'over': 'print', 'divide': 'print', 'invalid': 'print', 'under': 'ignore'}
    >>> 1/i


    Traceback (most recent call last):
    File "<pyshell#9>", line 1, in <module>
    1/i
    FloatingPointError: divide by zero encountered in long_scalars

    > You can get Python scalars out of NumPy arrays if you really want them
    > using (for example...)
    >
    > a.item(0,0)
    >
    >
    >>
    >> 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.
    >>

    >
    > Could you please post an example showing the problem?
    >


    [snip]

    -----------------example.py--------------------

    from __future__ import division

    import numpy

    class MyClass(object):

    def __init__(self, arr, labels):
    self.arr = arr
    self.labels = labels

    def __repr__(self):
    return numpy.array2string(self.arr, separator=', ') +
    repr(self.labels)

    def __len__(self):
    return len(self.labels)

    def __getitem__(self, key):
    return self.arr[key]

    def __setitem__(self, key, item):
    self.arr[key] = item

    def __mul__(self, other):
    return self.__class__(self.arr * other, self.labels)

    __rmul__ = __mul__

    ----------------------------------------------------

    >>> import example
    >>> import numpy as N
    >>> ex = example.MyClass(N.array([[6,7],[8,9]]), ['axis0', 'axis1'])
    >>> i = ex.arr[0,0]
    >>> ex

    [[6, 7],
    [8, 9]]['axis0', 'axis1']
    >>> ex * i

    [[36, 42],
    [48, 54]]['axis0', 'axis1']
    >>> i * ex

    array([[36, 42],
    [48, 54]])
    >>>



    It seems that it requires having __len__, __setitem__ and __getitem__
    defined to get the undesired behaviour. Cheers.

    Duncan
    Duncan Smith, Apr 25, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    2,402
    scwebgroup
    Jun 26, 2011
  2. Paul Dubois
    Replies:
    11
    Views:
    539
    Tom Loredo
    Jan 23, 2004
  3. Bruce Southey
    Replies:
    2
    Views:
    357
    Jesus Rivero (Neurogeek)
    Feb 21, 2006
  4. drife
    Replies:
    1
    Views:
    360
    Travis E. Oliphant
    Mar 1, 2006
  5. Boni Satani
    Replies:
    0
    Views:
    163
    Boni Satani
    Jan 9, 2014
Loading...

Share This Page