[Numpy-discussion] Old tickets

[Ralf Gommers]

On Wed, Mar 30, 2011 at 11:52 PM, Derek Homeier
<derek at astro.physik.uni-goettingen.de> wrote:
>
> On 30 Mar 2011, at 23:26, Benjamin Root wrote:
>
>> Ticket 301: 'Make power and divide return floats from int inputs (like
>> true_divide)'
>> http://projects.scipy.org/numpy/ticket/301
>> Invalid because the output dtype is the same as the input dtype unless
>> you override using the dtype argument:
>>  >>> np.power(3, 1, dtype=np.float128).dtype
>> dtype('float128')
>> Alternatively return a float and indicate in the docstring that the
>> output dtype can be changed.
>>
>>
>> FWIW,
>>
>> Just thought I'd note (on a python 2.6 system):
>>
>> >>> import numpy as np
>> >>> a = np.array([1, 2, 3, 4])
>> >>> a.dtype
>> dtype('int32')
>> >>> 2 / a
>> array([2, 1, 0, 0])
>> >>> from __future__ import division
>> >>> 2 / a
>> array([ 2.        ,  1.        ,  0.66666667,  0.5       ])
>>
>> So, numpy already does this when true division is imported (and
>> therefore consistent with whatever the python environment does), and
>> python currently also returns integers for exponentials when both
>> inputs are integers.
>
> I'd agree, and in my view power(3, -1) is well defined as 1 / 3 -
> also, in future (or Python3)
>
>  >>> a/2
> array([ 0.5,  1. ,  1.5,  2. ])
>  >>> a//2
> array([0, 1, 1, 2], dtype=int32)

The ticket is about the functions np.divide and np.power, not / and
**. This currently does not work the same, unlike what's said above:

>>> from __future__ import division
>>> x = np.arange(4) + 1
>>> 2 / x
array([ 2.        ,  1.        ,  0.66666667,  0.5       ])
>>> np.divide(2, x)
array([2, 1, 0, 0])

The power and divide functions should not check the "from __future__
import division", just return floats IMHO. This is what's expected by
most users, and much more useful than integer math.


> so I think at least a**n should follow integer math rules; depends on
> whether we want
> np.power to behave differently from ** (if they are internally handled
> separately at all)...
> Not sure if I understand the overload suggestion in the ticket

I don't understand that either, it'll just lead to more confusion.

Cheers,
Ralf