Travis Oliphant writes:
I have not heard any feedback back on my proposal to add a final object to the extended slice syntax to current Numeric to allow for unambiguous index and mask-array access.
As a modification to the proposal, suppose we just check to see if the last argument (of at least two) is a 0d array of type signed byte (currently this is illegal and will raise an error). This number would be a flag indicating how to interpret the previous objects. Of course these numbers would be hidden from the user who would write:
a[index_array, _I] = <values> b = a[index_array, _I]
or
a[mask_array, _M] = <values> b = a[mask_array, _M]
where _M is a 0d signed byte array indicating that the mask_array should be interpreted as a mask while _I is a 0d signed byte array indicating that the index_array should be interpreted as a integers into the flattened version of a.
Other indexing schemes could be envisioned as well
a[a1,a2,a3,_X] could be the cross product of the integer arrays a1, a2, and a3 for example.
or
a[a1, a2, a3, _Z] could select elements from a by "zipping" the sequences a1, a2, and a3 together to form a list of tuples to grab from a.
Comments?
Like Greg I'm wary of having many different interpretations for indexing behavior (I'm not even that crazy about having numarray handle boolean index arrays differently than the others --something we haven't implemented yet, and perhaps we shouldn't). Before discussing the merits of this, shouldn't we take the attitude that absence of feedback is not necessarily equivalent to approval, particularly for something that affects the public interface of the module? I would feel better about this if I saw several affirming the need for such features rather than few openly opposing it. But if one were to do something like this, I would use a different kind of object than 0d arrays, e.g., an instance of a class defined for just that purpose. You would really want to make sure that no data could mistakenly be interpreted as a flag, even if the chances were remote. I would also not use an underscore as the beginning of the name. Maybe I'm wrong about this, but I've come to take that to mean its a private variable that should not be used by users of the module, and that usage would confuse that. Finally, the name of the flag should be descriptive (e.g. MaskInd). But there could be better alternatives. As an example, x[nonzero(maskarray)] instead of x[maskarray, MaskInd] (Yes, it does generate a temporary so that is a drawback) Perry