Hi, I'm using NumPy 1.8.2: In [1]: np.array(0) / np.array(0) Out[1]: 0 In [2]: np.array(0) / np.array(0.0) Out[2]: nan In [3]: np.array(0.0) / np.array(0) Out[3]: nan In [4]: np.array(0.0) / np.array(0.0) Out[4]: nan In [5]: 0/0 --------------------------------------------------------------------------- ZeroDivisionError Traceback (most recent call last) <ipython-input-6-6549dea6d1ae> in <module>() ----> 1 0/0 ZeroDivisionError: integer division or modulo by zero Out[1] seems odd. I get the right value in 1.8.1. Was this fixed for 1.9.0?
On Thu, Oct 2, 2014 at 5:02 PM, T J <tjhnson@gmail.com> wrote:
Hi, I'm using NumPy 1.8.2:
In [1]: np.array(0) / np.array(0) Out[1]: 0
In [2]: np.array(0) / np.array(0.0) Out[2]: nan
In [3]: np.array(0.0) / np.array(0) Out[3]: nan
In [4]: np.array(0.0) / np.array(0.0) Out[4]: nan
In [5]: 0/0 --------------------------------------------------------------------------- ZeroDivisionError Traceback (most recent call last) <ipython-input-6-6549dea6d1ae> in <module>() ----> 1 0/0
ZeroDivisionError: integer division or modulo by zero
Out[1] seems odd. I get the right value in 1.8.1. Was this fixed for 1.9.0?
In master on Fedora I get In [1]: np.array(0) / np.array(0) /home/charris/.local/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide #!/usr/bin/python Out[1]: 0 Note that the warning is only given once, it's a warnings module thing. In [2]: np.array(0) / np.array(0) Out[2]: 0 And it might even be system dependent. Chuck
On Thu, Oct 2, 2014 at 4:29 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 5:02 PM, T J <tjhnson@gmail.com> wrote:
Hi, I'm using NumPy 1.8.2:
In [1]: np.array(0) / np.array(0) Out[1]: 0
In [2]: np.array(0) / np.array(0.0) Out[2]: nan
In [3]: np.array(0.0) / np.array(0) Out[3]: nan
In [4]: np.array(0.0) / np.array(0.0) Out[4]: nan
In [5]: 0/0
--------------------------------------------------------------------------- ZeroDivisionError Traceback (most recent call last) <ipython-input-6-6549dea6d1ae> in <module>() ----> 1 0/0
ZeroDivisionError: integer division or modulo by zero
Out[1] seems odd. I get the right value in 1.8.1. Was this fixed for 1.9.0?
In master on Fedora I get
In [1]: np.array(0) / np.array(0) /home/charris/.local/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide #!/usr/bin/python Out[1]: 0
Exact same thing on Windows with master:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions? Ben Root On Oct 2, 2014 7:02 PM, "T J" <tjhnson@gmail.com> wrote:
Hi, I'm using NumPy 1.8.2:
In [1]: np.array(0) / np.array(0) Out[1]: 0
In [2]: np.array(0) / np.array(0.0) Out[2]: nan
In [3]: np.array(0.0) / np.array(0) Out[3]: nan
In [4]: np.array(0.0) / np.array(0.0) Out[4]: nan
In [5]: 0/0 --------------------------------------------------------------------------- ZeroDivisionError Traceback (most recent call last) <ipython-input-6-6549dea6d1ae> in <module>() ----> 1 0/0
ZeroDivisionError: integer division or modulo by zero
Out[1] seems odd. I get the right value in 1.8.1. Was this fixed for 1.9.0?
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
<snip> Chuck
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
That's an option, although arguable for arrays of numbers. However, the fact that we don't know *which* numbers caused the problem strengthens the argument for an error. Chuck
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent
as an integer. Perhaps something weird was happening with type
nan promotion
between versions?
Also note that in python3 the '/' operator does float rather than integer division.
np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
That's an option, although arguable for arrays of numbers. However, the fact that we don't know *which* numbers caused the problem strengthens the argument for an error.
Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless. Chuck
slightly OT; but fwiw, its all ill-thought out nonsense from the start anyway. ALL numbers satisfy the predicate 0*x=0. what the IEEE calls 'not a number' would be more accurately called 'not a specific number', or 'a number'. whats a logical negation among computer scientists? On Fri, Oct 3, 2014 at 6:13 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent
as an integer. Perhaps something weird was happening with type
nan promotion
between versions?
Also note that in python3 the '/' operator does float rather than integer division.
> np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
That's an option, although arguable for arrays of numbers. However, the fact that we don't know *which* numbers caused the problem strengthens the argument for an error.
Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless.
I believe the idea is to only warn once per source location, i.e. if you write something like: z = np.zeros(()) for foo in range(1000): z / z z / z then you're supposed to get two warnings, for the two lines that contain divide-by-zero. And then there is an unfortunate interaction where all lines entered interactively are considered to be "the same line" for these purposes. I don't know why this happens. It's either a bug in ipython or in warnings. The weird thing is that ipython does give each line its own unique name (you can see 'filenames' like "<ipython-input-4-f23c7d6238bf>" in error tracebacks), but somehow the warning machinery doesn't pick up on this. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Fri, Oct 3, 2014 at 3:00 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless.
I believe the idea is to only warn once per source location, i.e. if you write something like:
z = np.zeros(()) for foo in range(1000): z / z z / z
then you're supposed to get two warnings, for the two lines that contain divide-by-zero.
What I want is that the following script would warn three times import numpy as np z = np.zeros(1, dtype=np.int) def f(x): return x/x f(z) f(z) f(z) But it only warns once. That is not helpful when f gets called with an erroneous argument from different places. <snip> Chuck
On 10/03/2014 11:24 PM, Charles R Harris wrote:
What I want is that the following script would warn three times
import numpy as np
z = np.zeros(1, dtype=np.int <http://np.int>)
def f(x): return x/x
f(z) f(z) f(z)
But it only warns once. That is not helpful when f gets called with an erroneous argument from different places.
Add import warnings warnings.simplefilter('always', RuntimeWarning) to get that effect. And as said before, if Numpy uses its own warning class it can put this filter in place automatically on import. You might also argue on python-dev to make RuntimeWarning default to "always" behavior in CPython, since dubious runtime features should always warn. Georg
On Fri, Oct 3, 2014 at 10:00 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless.
I believe the idea is to only warn once per source location, i.e. if you write something like:
z = np.zeros(()) for foo in range(1000): z / z z / z
then you're supposed to get two warnings, for the two lines that contain divide-by-zero.
And then there is an unfortunate interaction where all lines entered interactively are considered to be "the same line" for these purposes.
I don't know why this happens. It's either a bug in ipython or in warnings. The weird thing is that ipython does give each line its own unique name (you can see 'filenames' like "<ipython-input-4-f23c7d6238bf>" in error tracebacks), but somehow the warning machinery doesn't pick up on this.
Here's the solution: https://github.com/ipython/ipython/issues/6611 -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Fri, Oct 3, 2014 at 3:40 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 10:00 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless.
I believe the idea is to only warn once per source location, i.e. if you write something like:
z = np.zeros(()) for foo in range(1000): z / z z / z
then you're supposed to get two warnings, for the two lines that contain divide-by-zero.
And then there is an unfortunate interaction where all lines entered interactively are considered to be "the same line" for these purposes.
I don't know why this happens. It's either a bug in ipython or in warnings. The weird thing is that ipython does give each line its own unique name (you can see 'filenames' like "<ipython-input-4-f23c7d6238bf>" in error tracebacks), but somehow the warning machinery doesn't pick up on this.
Here's the solution: https://github.com/ipython/ipython/issues/6611
IPython isn't involved, it's a script. The problem is that the error occurs in the function, and when/if the same error occurs in the function, regardless of where the function is called from, it won't be reported. It wouldn't be so bad if the error was traced to the first rather than last entry on the call stack. Chuck
On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
Well, actually, that's the really nice thing about seterr for ints! CPUs have hardware floating point exception flags to work with. We had to build one for ints. If you want an error, you can get an error. *I* don't want an error, and I don't have to have one! -- Robert Kern
On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
Well, actually, that's the really nice thing about seterr for ints! CPUs have hardware floating point exception flags to work with. We had to build one for ints. If you want an error, you can get an error. *I* don't want an error, and I don't have to have one!
Sure, that's fine for integer computations corner cases that have well-defined outputs, like wraparound. But it doesn't make sense for divide-by-zero. The key thing about the IEEE754 exception design is that it gives you the option of either raising an error immediately or else letting it propagate through the computation as a nan until you reach an appropriate place to handle it. With ints we don't have nan, so we don't have the second option. Our options are either raise an error immediately, or else return some nonsense value that will just cause you to get some meaningless result, with no way to detect or recover from this situation. (Why don't we define 0 / 0 == -72? It would make just as much sense.) The second option is terrible enough that I kinda don't believe you when you say you want it. Maybe I'm missing something but... Even more egregiously, numpy currently treats the integer divide-by-zero case identically with the floating-point one -- so if you want 0 / 0 to be an error (as you have to if you care about getting correct results), then you have to make 0.0 / 0.0 an error as well. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Sat, Oct 4, 2014 at 12:21 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
> np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
Well, actually, that's the really nice thing about seterr for ints! CPUs have hardware floating point exception flags to work with. We had to build one for ints. If you want an error, you can get an error. *I* don't want an error, and I don't have to have one!
Sure, that's fine for integer computations corner cases that have well-defined outputs, like wraparound. But it doesn't make sense for divide-by-zero.
The key thing about the IEEE754 exception design is that it gives you the option of either raising an error immediately or else letting it propagate through the computation as a nan until you reach an appropriate place to handle it.
With ints we don't have nan, so we don't have the second option. Our options are either raise an error immediately, or else return some nonsense value that will just cause you to get some meaningless result, with no way to detect or recover from this situation. (Why don't we define 0 / 0 == -72? It would make just as much sense.)
The second option is terrible enough that I kinda don't believe you when you say you want it. Maybe I'm missing something but...
I fix the values after-the-fact because one *can* detect and recover from this situation with just a smidgen of forethought. <not-real-code> mask = (denominator == 0) x = numerator // denominator # We don't care about the masked cases. Fill them with a value that # will be harmless/ignored downstream. Here, it's 0. It might be something # else in other contexts. x[mask] = 0 </not-real-code>
Even more egregiously, numpy currently treats the integer divide-by-zero case identically with the floating-point one -- so if you want 0 / 0 to be an error (as you have to if you care about getting correct results), then you have to make 0.0 / 0.0 an error as well.
If you would like to introduce a separate `integer_divide` setting for errstate() and make it raise by default, I'd be marginally okay with that. In the above pattern, I'd be wrapping it with an errstate() context manager anyways to silence the warning, so silencing the default exception would be just as easy. However, nothing else in errstate() raises by default, so this would be the odd special case. -- Robert Kern
On Sat, Oct 4, 2014 at 12:40 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Oct 4, 2014 at 12:21 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote:
Out[1] has an integer divided by an integer, and you can't represent nan as an integer. Perhaps something weird was happening with type promotion between versions?
Also note that in python3 the '/' operator does float rather than integer division.
>> np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
> np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
Well, actually, that's the really nice thing about seterr for ints! CPUs have hardware floating point exception flags to work with. We had to build one for ints. If you want an error, you can get an error. *I* don't want an error, and I don't have to have one!
Sure, that's fine for integer computations corner cases that have well-defined outputs, like wraparound. But it doesn't make sense for divide-by-zero.
The key thing about the IEEE754 exception design is that it gives you the option of either raising an error immediately or else letting it propagate through the computation as a nan until you reach an appropriate place to handle it.
With ints we don't have nan, so we don't have the second option. Our options are either raise an error immediately, or else return some nonsense value that will just cause you to get some meaningless result, with no way to detect or recover from this situation. (Why don't we define 0 / 0 == -72? It would make just as much sense.)
The second option is terrible enough that I kinda don't believe you when you say you want it. Maybe I'm missing something but...
I fix the values after-the-fact because one *can* detect and recover from this situation with just a smidgen of forethought.
<not-real-code>
mask = (denominator == 0) x = numerator // denominator # We don't care about the masked cases. Fill them with a value that # will be harmless/ignored downstream. Here, it's 0. It might be something # else in other contexts. x[mask] = 0
</not-real-code>
I don't find this argument very convincing, except as an argument for having a deprecation period. In the unusual case where this is what you want, it's trivial and more explicit to write it directly -- bringing errstate into it is just rube goldbergian. E.g.: mask = (denominator == 0) x = np.floor_divide(numerator, denominator, where=~mask) x[mask] = 0
Even more egregiously, numpy currently treats the integer divide-by-zero case identically with the floating-point one -- so if you want 0 / 0 to be an error (as you have to if you care about getting correct results), then you have to make 0.0 / 0.0 an error as well.
If you would like to introduce a separate `integer_divide` setting for errstate() and make it raise by default, I'd be marginally okay with that. In the above pattern, I'd be wrapping it with an errstate() context manager anyways to silence the warning, so silencing the default exception would be just as easy. However, nothing else in errstate() raises by default, so this would be the odd special case.
In a perfect world (which may or not match the actual world) I actually would prefer integer wraparound to be treated as its own category (instead of being lumped with float overflow-to-inf), and to raise by default (with the option to enable it explicitly). Unexpected inf's give you correct results in some cases and obviously-broken results in others; unexpected wraparound tends to produce silent bugs in basically all integer using code [1]; lumping them together is pretty suboptimal. But that's a whole 'nother discussion... -n [1] http://googleresearch.blogspot.co.uk/2006/06/extra-extra-read-all-about-it-n... -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Sat, Oct 4, 2014 at 2:17 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Oct 4, 2014 at 12:40 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Oct 4, 2014 at 12:21 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root@ou.edu> wrote: > > Out[1] has an integer divided by an integer, and you can't represent nan > as an integer. Perhaps something weird was happening with type promotion > between versions?
Also note that in python3 the '/' operator does float rather than integer division.
>>> np.array(0) / np.array(0) __main__:1: RuntimeWarning: invalid value encountered in true_divide nan
Floor division still acts the same though:
>> np.array(0) // np.array(0) __main__:1: RuntimeWarning: divide by zero encountered in floor_divide 0
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
Well, actually, that's the really nice thing about seterr for ints! CPUs have hardware floating point exception flags to work with. We had to build one for ints. If you want an error, you can get an error. *I* don't want an error, and I don't have to have one!
Sure, that's fine for integer computations corner cases that have well-defined outputs, like wraparound. But it doesn't make sense for divide-by-zero.
The key thing about the IEEE754 exception design is that it gives you the option of either raising an error immediately or else letting it propagate through the computation as a nan until you reach an appropriate place to handle it.
With ints we don't have nan, so we don't have the second option. Our options are either raise an error immediately, or else return some nonsense value that will just cause you to get some meaningless result, with no way to detect or recover from this situation. (Why don't we define 0 / 0 == -72? It would make just as much sense.)
The second option is terrible enough that I kinda don't believe you when you say you want it. Maybe I'm missing something but...
I fix the values after-the-fact because one *can* detect and recover from this situation with just a smidgen of forethought.
<not-real-code>
mask = (denominator == 0) x = numerator // denominator # We don't care about the masked cases. Fill them with a value that # will be harmless/ignored downstream. Here, it's 0. It might be something # else in other contexts. x[mask] = 0
</not-real-code>
I don't find this argument very convincing, except as an argument for having a deprecation period. In the unusual case where this is what you want, it's trivial and more explicit to write it directly -- bringing errstate into it is just rube goldbergian. E.g.:
mask = (denominator == 0) x = np.floor_divide(numerator, denominator, where=~mask) x[mask] = 0
In any case, controlling the errstate() is important because that operation is often buried inside a function written by someone who made assumptions about the inputs. Even if I had remembered that we had added the `where=` keyword recently, I would still run into places where I needed to silence the error. This is an old, long-established pattern, not a rube goldbergian contraption. It's how all of numpy.ma works for domained operations like division.
Even more egregiously, numpy currently treats the integer divide-by-zero case identically with the floating-point one -- so if you want 0 / 0 to be an error (as you have to if you care about getting correct results), then you have to make 0.0 / 0.0 an error as well.
If you would like to introduce a separate `integer_divide` setting for errstate() and make it raise by default, I'd be marginally okay with that. In the above pattern, I'd be wrapping it with an errstate() context manager anyways to silence the warning, so silencing the default exception would be just as easy. However, nothing else in errstate() raises by default, so this would be the odd special case.
In a perfect world (which may or not match the actual world) I actually would prefer integer wraparound to be treated as its own category (instead of being lumped with float overflow-to-inf), and to raise by default (with the option to enable it explicitly). Unexpected inf's give you correct results in some cases and obviously-broken results in others; unexpected wraparound tends to produce silent bugs in basically all integer using code [1]; lumping them together is pretty suboptimal. But that's a whole 'nother discussion...
Well, it's up to you to make a concrete proposal. You have the opportunity to make the world you want. -- Robert Kern
On Thu, Oct 2, 2014 at 11:29 PM, Nathaniel Smith <njs@pobox.com> wrote:
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
+1 An even worse offender (in my opinion) is in-place addition of an integer array with np.nan:
x = np.zeros(1, dtype=int) x += np.nan RuntimeWarning: invalid value encountered in add x array([-9223372036854775808])
On Fri, Oct 3, 2014 at 1:33 AM, Stephan Hoyer <shoyer@gmail.com> wrote:
On Thu, Oct 2, 2014 at 11:29 PM, Nathaniel Smith <njs@pobox.com> wrote:
The seterr warning system makes a lot of sense for IEEE754 floats, which are specifically designed so that 0/0 has a unique well-defined answer. For ints though this seems really broken to me. 0 / 0 = 0 is just the wrong answer. It would be nice if we had something reasonable to return, but we don't, and I'd rather raise an error than return the wrong answer.
+1
An even worse offender (in my opinion) is in-place addition of an integer array with np.nan:
x = np.zeros(1, dtype=int) x += np.nan RuntimeWarning: invalid value encountered in add x array([-9223372036854775808])
This will be an error in 1.10 Chuck
participants (9)
-
Benjamin Root -
Charles R Harris -
Eelco Hoogendoorn -
Georg Brandl -
Jaime Fernández del Río -
Nathaniel Smith -
Robert Kern -
Stephan Hoyer -
T J