[Numpy-discussion] Rationale for returning type-wrapped min() / max() scalars? (was: Problem with ufunc of a numpy.ndarray derived class)

Benjamin Root ben.root at ou.edu
Fri Jul 29 12:32:54 EDT 2011


On Fri, Jul 29, 2011 at 10:07 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> On Thu, Jul 28, 2011 at 9:58 AM, Hans Meine <
> meine at informatik.uni-hamburg.de> wrote:
>
>> Hi again!
>>
>> Am Donnerstag, 21. Juli 2011, 16:56:21 schrieb Hans Meine:
>> > import numpy
>> >
>> > class Test(numpy.ndarray):
>> >     pass
>> >
>> > a1 = numpy.ndarray((1,))
>> > a2 = Test((1,))
>> >
>> > assert type(a1.min()) == type(a2.min()), \
>> >   "%s != %s" % (type(a1.min()), type(a2.min()))
>> > # ---------------------------------------------------
>> >
>> > This code fails with 1.6.0, while it worked in 1.3.0.
>>
>> I just tried with 1.5.1 (Ubuntu natty), and it works, too.
>>
>> Thus, this behavor-incompatible change happened between 1.5.1 and 1.6.0.
>>
>
> I dug a little bit into the relevant 1.5.x vs 1.6.x code, in the places I
> would most suspect a change, but couldn't find anything obvious. Here's the
> ndarray.min method:
>
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.5.x/numpy/core/src/multiarray/methods.c#L267
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.6.x/numpy/core/src/multiarray/methods.c#L257
>
> it calls PyArray_Min, which is here:
>
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.5.x/numpy/core/src/multiarray/calculation.c#L208
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.6.x/numpy/core/src/multiarray/calculation.c#L208
>
> this calls numpy.minimum.reduce, which ends up here:
>
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.5.x/numpy/core/src/umath/ufunc_object.c#L3194
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.6.x/numpy/core/src/umath/ufunc_object.c#L3851
>
> This function calls PyArray_Return(ret), which is how things get converted
> into the NumPy scalars:
>
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.5.x/numpy/core/src/umath/ufunc_object.c#L3365
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.6.x/numpy/core/src/umath/ufunc_object.c#L4019
>
> Here's the code for PyArray_Return, which was unchanged:
>
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.5.x/numpy/core/src/multiarray/scalarapi.c#L729
>
> https://github.com/numpy/numpy/blob/maintenance%2F1.6.x/numpy/core/src/multiarray/scalarapi.c#L793
>
> Something more subtle is going on. I don't have the time to dig into this
> more at the moment, but hopefully these pointers into the code can help
> anyone out there who has the time to investigate further. We definitely need
> to add some tests for the desired behavior here.
>
> Cheers,
> -Mark
>
>
Could it possibly have anything to do with the bug Chuck found in a
different thread:

No, it comes from this
>
> In [2]: a = numpy.ma.masked_array([1,2,3,
> 4])
>
> In [3]: array(a.flat)
> Out[3]: array(<numpy.ma.core.MaskedIterator object at 0x1fd1f90>,
> dtype='object')
>
> i.e., the a.flat iterator is turned into an object array with one element.
> I'm not sure what the correct fix for this would be. Please open a ticket.
>

Don't know if they are related, just throwing it out there.

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110729/eca49ba1/attachment.html>


More information about the NumPy-Discussion mailing list