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_view
for aSlice
doesn'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
Slice
information is lost, soIndexStyle
of 2D views might becomeIndexCartesian
once 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 theparentindices
of theSubArray
.Edit: the alternate approach is implemented now.