Fix no_offset_view for Slice #376
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the implementation of
no_offset_viewfor aSlicedoesn't actually ensure that there is no offset. This is becauseBase.Slice(UnitRange(a))hasUnitRange(a)as its axes, which are usually offset. This PR changes the behavior to return aUnitRange(a)instead.Fixes #375
The flip side of the current implementation is that the
Sliceinformation is lost, soIndexStyleof 2D views might becomeIndexCartesianonce they are routed throughno_offset_view.An alternate approach might be to shift the parent to one-based indices, and use
Base.Slice{Base.OneTo{Int}}axes, which preserve this information. This, however, departs from the current approach of preserving theparentindicesof theSubArray.Edit: the alternate approach is implemented now.