Reverting #694 #1027
jpivarski
started this conversation in
Deprecations
Reverting #694
#1027
Replies: 1 comment
-
PR #1028 removes the slice feature, as described above. It's an almost exact inverse of #694. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
PR #694 silently introduced a new slicing rule: if slicing with variable-length dimensions but one dimension has regular length 1, it would be expanded to fit the array you're slicing, to allow this:
The rule was introduced because it simplifies expressions in this tutorial that was never presented: https://github.com/jpivarski-talks/2021-02-09-propose-scipy2021-tutorial/blob/main/prep/million-song.ipynb (it was a proposal that wasn't accepted, and hence wasn't developed beyond its currently rough state).
The rule was justified because length-1 dimensions are expanded to fit the dimensions of other arrays in broadcasting, and NumPy advanced indexing broadcasts all arrays in a tuple before applying them as a slice, and I wanted a similar effect. However, there are several differences from the NumPy case: Awkward advanced indexing involves a single nested array, which has to match dimensions with the array you're slicing, whereas NumPy advanced indexing involves a tuple of arrays that get broadcasted together; in no case is the array used as a slice broadcasted with the array being sliced. The analogy is a little weak.
Moreover, the new rule has led to some erroneous cases, described in #1022, especially #1022 (comment). (The length-1 dimensions were supposed to be made with
np.newaxis
, but there are other ways to "accidentally" make length-1 dimensions.) Although the rule has been in the codebase for 6 months, it has never been advertised and probably hasn't been triggered until now because it relies on a mixture of regular and variable-length axes. (@agoose77 uses regular and mixed dimensions a lot.)Therefore, I will be removing this feature, restoring the "you need all dimensions in the slicer to be regular or variable-length" behavior that predated this rule. Slices like the above are still possible, but are more laborious to set up:
(The
[3, 4]
is replicated as many times as the length of the first list inarray
and the[0, 1, 2, 3]
is replicated as many times as the second list inarray
. If this needs to be a common idiom, we can find other ways to construct it; it'sslicer[[[0, 0, 0], [1, 1, 1]]]
.)This is not something that would be easy to turn into a deprecation cycle—note to self: I should not introduce slicing rules lightly!—but it turns something that is currently poorly defined into an error message. If you see this error message:
In something that worked in
awkward>=1.1.0rc2,<=1.4.0
and doesn't work inawkward>1.4.0
, then it is likely this. If this is still a need (originally issue #492), we'll find a different solution, some function that modifies the slicer to fit the array to be sliced, rather than implicitly taking regular length-1 dimensions to do that automatically.Beta Was this translation helpful? Give feedback.
All reactions