Skip to content
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

One-dimensional views assume their range index is 1-indexed #37199

Closed
jishnub opened this issue Aug 25, 2020 · 1 comment
Closed

One-dimensional views assume their range index is 1-indexed #37199

jishnub opened this issue Aug 25, 2020 · 1 comment
Assignees
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@jishnub
Copy link
Contributor

jishnub commented Aug 25, 2020

This happens if the range used to create the view does not span the entire axis of the parent array

julia> b = zeros(6, 2);

julia> r = Base.IdentityUnitRange(4:6);

julia> b[r, 2] .= 3
3-element view(::Array{Float64,2}, :, 2) with eltype Float64 with indices 4:6:
 3.0
 6.90395899974187e-310
 6.90395899973673e-310

julia> b
6×2 Array{Float64,2}:
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0
@mbauman mbauman self-assigned this Aug 25, 2020
@mbauman mbauman changed the title Views created with Base.IdentityUnitRange as an axis use incorrect linear indexing Views assume all range indexes are 1-indexed Aug 25, 2020
@mbauman
Copy link
Member

mbauman commented Aug 25, 2020

This is just an overzealous <:AbstractUnitRange method that optimizes for one range index within the SubArray implementation.

@mbauman mbauman added the bug Indicates an unexpected problem or unintended behavior label Aug 25, 2020
@mbauman mbauman changed the title Views assume all range indexes are 1-indexed One-dimensional views assume their range index is 1-indexed Aug 25, 2020
mbauman added a commit that referenced this issue Aug 25, 2020
We had been assuming that IdentityUnitRange matched the indices of the parent (like Slices) but they define their own offset axes. Further, other `AbstractRanges` may be similarly offset. We do not need to consider other offset `AbstractArrays` as this code only applies to `IndexLinear` `SubArray`s.
@KristofferC KristofferC mentioned this issue Aug 26, 2020
29 tasks
simeonschaub pushed a commit to simeonschaub/julia that referenced this issue Aug 29, 2020
…Lang#37204)

We had been assuming that IdentityUnitRange matched the indices of the parent (like Slices) but they define their own offset axes. Further, other `AbstractRanges` may be similarly offset. We do not need to consider other offset `AbstractArrays` as this code only applies to `IndexLinear` `SubArray`s.
KristofferC pushed a commit that referenced this issue Sep 7, 2020
We had been assuming that IdentityUnitRange matched the indices of the parent (like Slices) but they define their own offset axes. Further, other `AbstractRanges` may be similarly offset. We do not need to consider other offset `AbstractArrays` as this code only applies to `IndexLinear` `SubArray`s.

(cherry picked from commit 701885b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants