-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
slice leads to broken indexing #2644
Labels
needs decision
A decision on this change is needed
Comments
It's also worth throwing in that thinking about the possibility of a "zero-copy reshape()" on subarrays leads one to toy with some funky new range objects (e.g., that map a 2d set of strided locations to 1d). I'm not saying I want to tackle that anytime soon, but I bet it will come up eventually. |
I was able to find a conservative fix, so I just went with that. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I haven't played much with subarrays and
slice
until very recently. Unfortunately, I've discovered some problems (present in both 0.1 and 0.2):Obviously the
getindex/ref
behavior is a problem. Withsub
, the values are correct, but really it should be a5 SubArray
rather than a1x5 SubArray
, because the parent is two dimensional and we're snipping out a column. Also note a curiosity:and of course
In thinking through how to fix this, I came to the conclusion that there's another problem: currently there no "immediate" way to link the dimensions in
indexes
to the dimensions instrides
. You can figure it out, but it takes some computation.I'm inclined to suggest that we do away with the
indexes
field altogether and compute everything fromstrides
andfirst_index
, basically treating the parent as if it's just a linear buffer. If the user really needs to know how a subarray would be created from the parent, we could provide a function that computes those indexes (plus a BitArray containing information about whether singleton dimensions would have to be dropped). But for general array indexing I suspect theindexes
field is really just a distraction tempting one into delivering the wrong answer.If we do that, how much would it break? I don't see references to the
indexes
field outside ofsubarray
, but of course there's a lot of code out there that I don't know about.The text was updated successfully, but these errors were encountered: