You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Specifically, ndarray.__getitem__ handles the case where the requested indices are 2-element list, similar to the output of np.where, but a list rather than a tuple.
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
<ipython-input-108-d8376781920d> in <module>()
1 a = ra.RaggedArray([np.arange(3), np.arange(4), np.arange(2)])
----> 2 a[list(zip( (1, 2), (2, 0), (0, 0) ))]
/home/jrporter/modules/enspara/util/array.py in __getitem__(self, iis)
455 elif (type(iis) is slice) or (type(iis) is list) \
456 or (type(iis) is np.ndarray):
--> 457 return RaggedArray(self._array[iis])
458 # tuples get index conversion from 2d to 1d
459 elif type(iis) is tuple:
IndexError: too many indices for array
IIRC this tuple/list issue is one of the things that was gave me a lot of trouble when I wrote the __getitem__ we wound up not using. (I don't remember if I eventually figured it out or not.)
Anyway, it looks like the __getitem__ we currently have implemented attempts to use the type of the indexer ("iis") as an proxy for the meaning of the contained data. I would suggest using the length of the data instead. As a probably-flawed example of what I'm suggesting, if the list only has two elements of matching dimensions, then it's an np.where-result-like indexer. If it instead is a list of many elements of one dimension, then it can be interpreted as a list of indices in the appropriate dimension.
The text was updated successfully, but these errors were encountered:
In numpy, it is possible to do the following:
Specifically,
ndarray.__getitem__
handles the case where the requested indices are 2-element list, similar to the output ofnp.where
, but a list rather than a tuple.Similar code on a
RaggedArray
:fails with
The very-similar following succeeds:
IIRC this tuple/list issue is one of the things that was gave me a lot of trouble when I wrote the
__getitem__
we wound up not using. (I don't remember if I eventually figured it out or not.)Anyway, it looks like the
__getitem__
we currently have implemented attempts to use the type of the indexer ("iis
") as an proxy for the meaning of the contained data. I would suggest using the length of the data instead. As a probably-flawed example of what I'm suggesting, if the list only has two elements of matching dimensions, then it's annp.where
-result-like indexer. If it instead is a list of many elements of one dimension, then it can be interpreted as a list of indices in the appropriate dimension.The text was updated successfully, but these errors were encountered: