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

[Matthew Brett]

Hi,

On Thu, Jul 28, 2011 at 7: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 tend to think that this is a bug (after all, a1.min() does not return
>> ndarray, but an array scalar), but maybe there is also a good reason for
>> this (for us, unexpected) behavor change and a nice solution?
>
> Unfortunately, I did not receive any answers so far.

Sorry about the lack of replies.

If I understand you correctly, the problem is that, for 1.5.1:

>>> class Test(np.ndarray): pass
>>> type(np.min(Test((1,))))
<type 'numpy.float64'>

and for 1.6.0 (and current trunk):

>>> class Test(np.ndarray): pass
>>> type(np.min(Test((1,))))
<class '__main__.Test'>

So, 1.6.0 is returning a zero-dimensional scalar of the given type,
and 1.5.1 returns a python scalar.

Zero dimensional scalars are designed to behave in a similar way to
python scalars, so the change should be all but invisible in practice.
 Was there a particular case you ran into where this was a problem?

Best,

Matthew