[Numpy-discussion] Proposal to make power return float, and other such things.

josef.pktd at gmail.com josef.pktd at gmail.com
Tue Feb 18 09:54:13 EST 2014


On Tue, Feb 18, 2014 at 9:42 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Tue, Feb 18, 2014 at 2:37 PM,  <josef.pktd at gmail.com> wrote:
>> On Tue, Feb 18, 2014 at 8:53 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>> On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>>> On 18 Feb 2014 07:07, "Robert Kern" <robert.kern at gmail.com> wrote:
>>>>>
>>>>> On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>>>> > Perhaps integer power should raise an error on negative powers? That way
>>>>> > people will at least be directed to use arr ** -1.0 instead of silently
>>>>> > getting nonsense from arr ** -1.
>>>>>
>>>>> Controllable by np.seterr(invalid=...)? I could get behind that.
>>>>
>>>> I'm not sure the np.seterr part would work or be a good idea, given that we
>>>> have no way to return or propagate NaN... I vote for just an unconditional
>>>> error.
>>>
>>> <shrug> We issue configurable warning/error/ignore behavior for
>>> integer 0/0 through this mechanism too without any NaNs. However,
>>> that's `divide` and not `invalid`. Your point is taken that `invalid`
>>> usually implies that a `NaN` is generated, though I don't think this
>>> is ever stated anywhere. I just suggested `invalid` as that is usually
>>> what we use for function domain violations.
>>
>> I thought 0/0 = 0 has been removed a few versions ago. Does numpy
>> still have silent casting of nan to 0 in ints.
>
> There is no casting involved.

numpy still creates a return dtype, that holds the wrong result.

>
>> I thought invalid and divide error/warnings are for floating point
>> when we want to signal that the outcome is nan or inf, not that we are
>> casting and return a result that is just wrong.
>
> No, they are also for some integer operations without going through a
> floating point intermediate.

good that I don't like integers, I didn't see a bug because of this in years.

at least for division, we can go into the __future__

with python 3.3:
>>> np.array(0) ** np.array(-1)
-2147483648
>>> np.divide(np.array(0), np.array(0))
nan
>>> np.array(0) / np.array(0)
nan

Josef

>
> --
> Robert Kern
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



More information about the NumPy-Discussion mailing list