Re: [Numpy-discussion] 0/0 == 0?
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Sat, Oct 4, 2014 at 2:17 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Oct 4, 2014 at 12:40 AM, Robert Kern robert.k...@gmail.com wrote: On Sat, Oct 4, 2014 at 12:21 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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
Re: [Numpy-discussion] 0/0 == 0?
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.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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. 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Thu, Oct 2, 2014 at 11:29 PM, Nathaniel Smith n...@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]) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 1:33 AM, Stephan Hoyer sho...@gmail.com wrote: On Thu, Oct 2, 2014 at 11:29 PM, Nathaniel Smith n...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On 10/03/2014 06:13 AM, Charles R Harris wrote: Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless. If you use a custom warning, there's no reason why you couldn't set a filter that shows it every time by default. Georg ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 3:00 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 10:00 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 3:40 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 10:00 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 5:13 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Sat, Oct 4, 2014 at 12:21 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Sat, Oct 4, 2014 at 12:40 AM, Robert Kern robert.k...@gmail.com wrote: On Sat, Oct 4, 2014 at 12:21 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 8:12 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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-nearly.html -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 0/0 == 0?
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
Re: [Numpy-discussion] 0/0 == 0?
On Thu, Oct 2, 2014 at 5:02 PM, T J tjhn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Thu, Oct 2, 2014 at 4:29 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 5:02 PM, T J tjhn...@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: ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
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 tjhn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 0/0 == 0?
On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root ben.r...@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. 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
