possible bug with numpy.object_
![](https://secure.gravatar.com/avatar/04845725f17da616f0eb8a6de05be3d9.jpg?s=120&d=mm&r=g)
is the following behaviour expected? or is this a bug with numpy.object_ ? I'm using numpy 1.0b1
Thanks, - Matt Knox _________________________________________________________________ Be one of the first to try Windows Live Mail. http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-491...
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Matt Knox wrote:
Not in this case. Explictly creating an object array from any object (even the empty-list object) gives you a 0-d array containing that object. When you explicitly create an object array a different section of code handles it and gives this result. This is a recent change, and I don't think this use-case was considered as a backward incompatibility (which I believe it is). Perhaps we should make it so array([],....) always returns an empty array. I'm not sure. Comments? -Travis
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 8/30/06, Stefan van der Walt <stefan@sun.ac.za> wrote:
Yes, including one more term in this check: In [5]: N.array([],dtype=object).size Out[5]: 1 In [6]: N.array([[]],dtype=object).size Out[6]: 1 In [7]: N.array([[],[]],dtype=object).size Out[7]: 2 Intuitively, I'd have expected the answers to be 0,1,2, instead of 1,1,2. Cheers, f
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Fernando Perez wrote:
What about N.array(3).size N.array([3]).size N.array([3,3]).size Essentially, the [] is being treated as an object when you explicitly ask for an object array in exactly the same way as 3 is being treated as a number in the default case. It's just that '[' ']' is "also" being used as the dimension delimiter and thus the confusion. It is consistent. It's a corner case, and I have no problem fixing the special-case code running when dtype=object so that array([], dtype=object) returns an empty array, if that is the consensus. -Travis
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 8/31/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
I wasn't really complaining: these are corner cases I've never seen in real use, so I'm not really sure how critical it is to worry about them. Though I could see code which does automatic size/shape checks tripping on some of them. The shape tuples shed a bit of light on what's going on for the surprised (like myself): In [8]: N.array(3).shape Out[8]: () In [9]: N.array([3]).shape Out[9]: (1,) In [10]: N.array([3,3]).shape Out[10]: (2,) In [11]: N.array([]).shape Out[11]: (0,) In [12]: N.array([[]]).shape Out[12]: (1, 0) In [13]: N.array([[],[]]).shape Out[13]: (2, 0) I won't really vote for any changes one way or another, as far as I'm concerned it's one of those 'learn the library' things. I do realize that the near-ambiguity between '[]' as an empty object and '[]' as the syntactic delimiter for a container makes this case a bit of a gotcha. I guess my only remaining question is: what is the difference between outputs #8 and #11 above? Is an empty shape tuple == array scalar, while a (0,) shape indicates a one-dimensional array with no elements? If this interpretation is correct, what is the usage of the latter kind of object, given how it can't even be indexed? In [15]: N.array([])[0] --------------------------------------------------------------------------- exceptions.IndexError Traceback (most recent call last) /home/fperez/research/code/mjmdim/pycode/<ipython console> IndexError: index out of bounds And is this really expected? In [18]: N.array([]).any() Out[18]: False In [19]: N.array([]).all() Out[19]: True It's a bit funny to have an array for which 'no elements are true' (any==false), yet 'all are true' (all==true), isn't it? Regards, f
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On 8/31/06, Fernando Perez <fperez.net@gmail.com> wrote:
This could be interpreted as : exists x, x element of array, s.t. x is true. In [19]: N.array([]).all()
Out[19]: True
Seems right: for all x, x element of array, x is true. It's a bit funny to have an array for which 'no elements are true'
(any==false), yet 'all are true' (all==true), isn't it?
Fun with empty sets! The question is, is a zero dimensional array an empty container or does it contain its value. The numpy choice of treating zero dimensional arrays as both empty containers and scalar values makes the determination a bit ambiguous although it is consistent with the indexing convention. Chuck
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Fernando Perez wrote:
In [8]: N.array(3).shape Out[8]: ()
In [11]: N.array([]).shape Out[11]: (0,)
It can be iterated over (with zero iterations):
whereas the scalar can not:
Of course the scalar isn't empty, so ti's different in that way too. Can there be an empty scalar? It doesn't look like it. In fact, this looks like it may be a bug:
That's what I'd expect, but what if you start with a (0,) array:
where did that zero come from?
N.__version__ '1.0b4'
-Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/5b2449484c19f8e037c5d9c71e429508.jpg?s=120&d=mm&r=g)
Christopher Barker wrote:
More or less from: >>> numpy.add.identity 0 All the ufuncs have an identity function that they use as a starting point for reduce and accumulate. Sum doesn't appear to actually ahve one, but since it's more or less the same as add.reduce it's probably good that it has the same behavior. Note that this also matches the behavior of python's built in sum, although there the identity is called 'start'. -tim
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote:
I'm not totally sure, but I think I'd rather it raise an exception. However, if it's not going to, then 0 is really the only reasonable answer. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On 8/31/06, Christopher Barker <Chris.Barker@noaa.gov> wrote:
I think that is correct, sums over empty sets are conventionally set to zero because they are conceived of as adding all the values in the set to zero. Typically this would be implemented as sum = 0 for i in set : sum += i; Chuck
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Matt Knox wrote:
Not in this case. Explictly creating an object array from any object (even the empty-list object) gives you a 0-d array containing that object. When you explicitly create an object array a different section of code handles it and gives this result. This is a recent change, and I don't think this use-case was considered as a backward incompatibility (which I believe it is). Perhaps we should make it so array([],....) always returns an empty array. I'm not sure. Comments? -Travis
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 8/30/06, Stefan van der Walt <stefan@sun.ac.za> wrote:
Yes, including one more term in this check: In [5]: N.array([],dtype=object).size Out[5]: 1 In [6]: N.array([[]],dtype=object).size Out[6]: 1 In [7]: N.array([[],[]],dtype=object).size Out[7]: 2 Intuitively, I'd have expected the answers to be 0,1,2, instead of 1,1,2. Cheers, f
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Fernando Perez wrote:
What about N.array(3).size N.array([3]).size N.array([3,3]).size Essentially, the [] is being treated as an object when you explicitly ask for an object array in exactly the same way as 3 is being treated as a number in the default case. It's just that '[' ']' is "also" being used as the dimension delimiter and thus the confusion. It is consistent. It's a corner case, and I have no problem fixing the special-case code running when dtype=object so that array([], dtype=object) returns an empty array, if that is the consensus. -Travis
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
On 8/31/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
I wasn't really complaining: these are corner cases I've never seen in real use, so I'm not really sure how critical it is to worry about them. Though I could see code which does automatic size/shape checks tripping on some of them. The shape tuples shed a bit of light on what's going on for the surprised (like myself): In [8]: N.array(3).shape Out[8]: () In [9]: N.array([3]).shape Out[9]: (1,) In [10]: N.array([3,3]).shape Out[10]: (2,) In [11]: N.array([]).shape Out[11]: (0,) In [12]: N.array([[]]).shape Out[12]: (1, 0) In [13]: N.array([[],[]]).shape Out[13]: (2, 0) I won't really vote for any changes one way or another, as far as I'm concerned it's one of those 'learn the library' things. I do realize that the near-ambiguity between '[]' as an empty object and '[]' as the syntactic delimiter for a container makes this case a bit of a gotcha. I guess my only remaining question is: what is the difference between outputs #8 and #11 above? Is an empty shape tuple == array scalar, while a (0,) shape indicates a one-dimensional array with no elements? If this interpretation is correct, what is the usage of the latter kind of object, given how it can't even be indexed? In [15]: N.array([])[0] --------------------------------------------------------------------------- exceptions.IndexError Traceback (most recent call last) /home/fperez/research/code/mjmdim/pycode/<ipython console> IndexError: index out of bounds And is this really expected? In [18]: N.array([]).any() Out[18]: False In [19]: N.array([]).all() Out[19]: True It's a bit funny to have an array for which 'no elements are true' (any==false), yet 'all are true' (all==true), isn't it? Regards, f
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On 8/31/06, Fernando Perez <fperez.net@gmail.com> wrote:
This could be interpreted as : exists x, x element of array, s.t. x is true. In [19]: N.array([]).all()
Out[19]: True
Seems right: for all x, x element of array, x is true. It's a bit funny to have an array for which 'no elements are true'
(any==false), yet 'all are true' (all==true), isn't it?
Fun with empty sets! The question is, is a zero dimensional array an empty container or does it contain its value. The numpy choice of treating zero dimensional arrays as both empty containers and scalar values makes the determination a bit ambiguous although it is consistent with the indexing convention. Chuck
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Fernando Perez wrote:
In [8]: N.array(3).shape Out[8]: ()
In [11]: N.array([]).shape Out[11]: (0,)
It can be iterated over (with zero iterations):
whereas the scalar can not:
Of course the scalar isn't empty, so ti's different in that way too. Can there be an empty scalar? It doesn't look like it. In fact, this looks like it may be a bug:
That's what I'd expect, but what if you start with a (0,) array:
where did that zero come from?
N.__version__ '1.0b4'
-Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/5b2449484c19f8e037c5d9c71e429508.jpg?s=120&d=mm&r=g)
Christopher Barker wrote:
More or less from: >>> numpy.add.identity 0 All the ufuncs have an identity function that they use as a starting point for reduce and accumulate. Sum doesn't appear to actually ahve one, but since it's more or less the same as add.reduce it's probably good that it has the same behavior. Note that this also matches the behavior of python's built in sum, although there the identity is called 'start'. -tim
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote:
I'm not totally sure, but I think I'd rather it raise an exception. However, if it's not going to, then 0 is really the only reasonable answer. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On 8/31/06, Christopher Barker <Chris.Barker@noaa.gov> wrote:
I think that is correct, sums over empty sets are conventionally set to zero because they are conceived of as adding all the values in the set to zero. Typically this would be implemented as sum = 0 for i in set : sum += i; Chuck
participants (7)
-
Charles R Harris
-
Christopher Barker
-
Fernando Perez
-
Matt Knox
-
Stefan van der Walt
-
Tim Hochberg
-
Travis Oliphant