Hi All, I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here<http://thread.gmane.org/gmane.comp.python.numeric.general/21526/focus=21537>. The problems that arise come from conversion to different types. In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.]) In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1]) In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool) In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.]) In [30]: bool(NaN) Out[30]: True So there are problems with at minimum the following. 1) The way NaN is converted to bool. I think it should be False. 2) The way NaN is converted to int types. I think it should be 0. These problems show up in failing tests. I'm reverting the fix for now, but I wonder what we should do about these things. Chuck
On Sun, Jul 20, 2008 at 17:42, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here. The problems that arise come from conversion to different types.
In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.])
In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1])
In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool)
In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.])
In [30]: bool(NaN) Out[30]: True
So there are problems with at minimum the following.
1) The way NaN is converted to bool. I think it should be False.
It's not really our choice. That's Python's bool(). For the things that are our choice (e.g. array([nan]).astype(bool)) I think we should stay consistent with Python.
2) The way NaN is converted to int types. I think it should be 0.
I agree. That's what int(nan) gives:
int(nan) 0L
-- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Jul 20, 2008 at 4:47 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 20, 2008 at 17:42, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here. The problems that arise come from conversion to different types.
In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.])
In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1])
In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool)
In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.])
In [30]: bool(NaN) Out[30]: True
So there are problems with at minimum the following.
1) The way NaN is converted to bool. I think it should be False.
It's not really our choice. That's Python's bool(). For the things that are our choice (e.g. array([nan]).astype(bool)) I think we should stay consistent with Python.
2) The way NaN is converted to int types. I think it should be 0.
I agree. That's what int(nan) gives:
int(nan) 0L
So we should shoot for: nan -> bool : True nan -> integer kind : 0 nan -> complex : Nan+0j nan -> string kind : ?, currently it is any one of 'n', 'na', 'nan', depending on string length. nan -> object: float object nan. Chuck
On Sun, Jul 20, 2008 at 20:32, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Jul 20, 2008 at 4:47 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 20, 2008 at 17:42, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here. The problems that arise come from conversion to different types.
In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.])
In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1])
In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool)
In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.])
In [30]: bool(NaN) Out[30]: True
So there are problems with at minimum the following.
1) The way NaN is converted to bool. I think it should be False.
It's not really our choice. That's Python's bool(). For the things that are our choice (e.g. array([nan]).astype(bool)) I think we should stay consistent with Python.
2) The way NaN is converted to int types. I think it should be 0.
I agree. That's what int(nan) gives:
int(nan) 0L
So we should shoot for:
nan -> bool : True nan -> integer kind : 0 nan -> complex : Nan+0j nan -> string kind : ?, currently it is any one of 'n', 'na', 'nan', depending on string length. nan -> object: float object nan.
Sounds right. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Jul 20, 2008 at 3:47 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 20, 2008 at 17:42, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here. The problems that arise come from conversion to different types.
In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.])
In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1])
In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool)
In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.])
In [30]: bool(NaN) Out[30]: True
So there are problems with at minimum the following.
1) The way NaN is converted to bool. I think it should be False.
It's not really our choice. That's Python's bool(). For the things that are our choice (e.g. array([nan]).astype(bool)) I think we should stay consistent with Python.
<DELURK> I agree that this is a good goal. However, in the past, Python's treatment of NaNs has been rather platform dependent and add hock. In this case, I suspect that you are OK since the section "Truth Value Testing" in the Python docs is pretty clear that any non-zero value of a numerical type is True. However...
2) The way NaN is converted to int types. I think it should be 0.
I agree. That's what int(nan) gives:
int(nan) 0L
This is GvR in http://mail.python.org/pipermail/python-dev/2008-January/075865.html: *If long(nan) or int(nan) returns 0 on most platforms in 2.5, we should* *fix them to always return 0 in 2.5 *and* 2.6. In 3.0 they should raise* *ValueError.* This implies that in version 2.4 and earlier, the Python behaviour is platform dependent. And that 3.0 this is going to change to raise a ValueError. Whether it's more important to match current behaviour (return 0) or future behaviour (raise ValueError), I'm not certain. I would lean towards a ValueError since it's less long term pain and it's IMO more correct.
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- . __ . |-\ . . tim.hochberg@ieee.org
On Sun, Jul 20, 2008 at 8:32 PM, Timothy Hochberg <tim.hochberg@ieee.org> wrote:
On Sun, Jul 20, 2008 at 3:47 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 20, 2008 at 17:42, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here. The problems that arise come from conversion to different types.
In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.])
In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1])
In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool)
In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.])
In [30]: bool(NaN) Out[30]: True
So there are problems with at minimum the following.
1) The way NaN is converted to bool. I think it should be False.
It's not really our choice. That's Python's bool(). For the things that are our choice (e.g. array([nan]).astype(bool)) I think we should stay consistent with Python.
<DELURK>
I agree that this is a good goal. However, in the past, Python's treatment of NaNs has been rather platform dependent and add hock. In this case, I suspect that you are OK since the section "Truth Value Testing" in the Python docs is pretty clear that any non-zero value of a numerical type is True.
However...
2) The way NaN is converted to int types. I think it should be 0.
I agree. That's what int(nan) gives:
int(nan) 0L
This is GvR in http://mail.python.org/pipermail/python-dev/2008-January/075865.html:
Well, now, that opens a whole other bag of toasted scorpions. It looks like long(inf) and int(inf) already raise OverflowError and
that should stay.
In [3]: (ones(2)*float(inf)).astype(int8) Out[3]: array([0, 0], dtype=int8) In [4]: (ones(2)*float(inf)).astype(int32) Out[4]: array([-2147483648, -2147483648]) In [5]: (ones(2)*float(inf)).astype(int64) Out[5]: array([-9223372036854775808, -9223372036854775808], dtype=int64) Hmmm, Chuck
On Sun, Jul 20, 2008 at 10:41 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sun, Jul 20, 2008 at 8:32 PM, Timothy Hochberg <tim.hochberg@ieee.org> wrote:
On Sun, Jul 20, 2008 at 3:47 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sun, Jul 20, 2008 at 17:42, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here. The problems that arise come from conversion to different types.
In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.])
In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1])
In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool)
In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.])
In [30]: bool(NaN) Out[30]: True
So there are problems with at minimum the following.
1) The way NaN is converted to bool. I think it should be False.
It's not really our choice. That's Python's bool(). For the things that are our choice (e.g. array([nan]).astype(bool)) I think we should stay consistent with Python.
<DELURK>
I agree that this is a good goal. However, in the past, Python's treatment of NaNs has been rather platform dependent and add hock. In this case, I suspect that you are OK since the section "Truth Value Testing" in the Python docs is pretty clear that any non-zero value of a numerical type is True.
However...
2) The way NaN is converted to int types. I think it should be 0.
I agree. That's what int(nan) gives:
int(nan) 0L
This is GvR in http://mail.python.org/pipermail/python-dev/2008-January/075865.html:
Well, now, that opens a whole other bag of toasted scorpions.
It looks like long(inf) and int(inf) already raise OverflowError and
that should stay.
In [3]: (ones(2)*float(inf)).astype(int8) Out[3]: array([0, 0], dtype=int8)
In [4]: (ones(2)*float(inf)).astype(int32)
Out[4]: array([-2147483648, -2147483648])
In [5]: (ones(2)*float(inf)).astype(int64) Out[5]: array([-9223372036854775808, -9223372036854775808], dtype=int64)
Also, In [8]: (ones(2)*float(inf)).astype(uint8) Out[8]: array([0, 0], dtype=uint8) In [9]: (ones(2)*float(inf)).astype(uint16) Out[9]: array([0, 0], dtype=uint16) In [10]: (ones(2)*float(inf)).astype(uint32) Out[10]: array([0, 0], dtype=uint32) In [11]: (ones(2)*float(inf)).astype(uint64) Out[11]: array([0, 0], dtype=uint64) Chuck
participants (3)
-
Charles R Harris -
Robert Kern -
Timothy Hochberg