Should 0-d arrays with fields defined return a 0-d array or a scalar
Hi all, Ticket #474 discusses the problem that getting a field from a 0-d array automatically produces a scalar (which then cannot be set). This produces the problem that recarrays code must often special-case the 0-d possibility. Thus, rarr.x[...] = blah doesn't work for 0-d arrays because rarr.x is a scalar. It makes some sense to make field selection for 0-d arrays return 0-d arrays as consistent with the changes that were made prior to the 1.0 release to allow persistence of 0-d arrays. However, changing field selection to return 0-d arrays does change behavior. A 0-d array is not a scalar (the 0-d array is not hashable for example, and the 0-d string array does not inherit from the Python string). Thus, just making the change, may not be advised. It is easy to account for and fix any errors that might arise. But, we are in a major release, I need some advice as to whether or not this is a "bug-fix" or a feature enhancement that must wait for 1.1? Any stake holders in the current behavior of arrays with records? -Travis
Hi Travis, We will need a little time to inspect our code to see if this is going to be a problem for us. We can't think of any major problems with this change off the top of our heads. Chris Travis Oliphant wrote:
Hi all,
Ticket #474 discusses the problem that getting a field from a 0-d array automatically produces a scalar (which then cannot be set). This produces the problem that recarrays code must often special-case the 0-d possibility.
Thus,
rarr.x[...] = blah
doesn't work for 0-d arrays because rarr.x is a scalar.
It makes some sense to make field selection for 0-d arrays return 0-d arrays as consistent with the changes that were made prior to the 1.0 release to allow persistence of 0-d arrays.
However, changing field selection to return 0-d arrays does change behavior. A 0-d array is not a scalar (the 0-d array is not hashable for example, and the 0-d string array does not inherit from the Python string). Thus, just making the change, may not be advised.
It is easy to account for and fix any errors that might arise. But, we are in a major release, I need some advice as to whether or not this is a "bug-fix" or a feature enhancement that must wait for 1.1?
Any stake holders in the current behavior of arrays with records?
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338
Hi Travis, This change should not have any impact on our code. We are not opposed to making the change as part of the 1.0.2 release. Chris Christopher Hanley wrote:
Hi Travis,
We will need a little time to inspect our code to see if this is going to be a problem for us. We can't think of any major problems with this change off the top of our heads.
Chris
Does this mean, we could do something like this? a = 3 a = array(a) a[ a<4 ] = 5 If so, that would be great! Mark On Mar 29, 9:20 pm, Travis Oliphant <oliphant.tra...@ieee.org> wrote:
Hi all,
Ticket #474 discusses the problem that getting a field from a 0-d array automatically produces a scalar (which then cannot be set). This produces the problem that recarrays code must often special-case the 0-d possibility.
Thus,
rarr.x[...] = blah
doesn't work for 0-d arrays because rarr.x is a scalar.
It makes some sense to make field selection for 0-d arrays return 0-d arrays as consistent with the changes that were made prior to the 1.0 release to allow persistence of 0-d arrays.
However, changing field selection to return 0-d arrays does change behavior. A 0-d array is not a scalar (the 0-d array is not hashable for example, and the 0-d string array does not inherit from the Python string). Thus, just making the change, may not be advised.
It is easy to account for and fix any errors that might arise. But, we are in a major release, I need some advice as to whether or not this is a "bug-fix" or a feature enhancement that must wait for 1.1?
Any stake holders in the current behavior of arrays with records?
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discuss...@scipy.orghttp://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (4)
-
Christopher Hanley
-
mark
-
Travis Oliphant
-
Travis Oliphant