-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Define in
for CartesianIndex
ranges
#58616
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
Conversation
c14852c
to
38c0ef1
Compare
Ref #57034 This PR seems to reinforce the view that ranges are collections of objects, and not intervals. I'm not sure it's relevant, but I think I remember people being of two minds about this, so I thought I'd mention it. |
For what it's worth, this PR was motivated by failing to compute the intersection of these ranges, which is used in checking for aliasing. I believe Closes #57034, and the suggested implementation in that issue is pretty similar to this one. |
Currently, this hits a fallback method that assumes that division is defined for the elements of the range. After this, the following works: ```julia julia> r = StepRangeLen(CartesianIndex(1), CartesianIndex(1), 3); julia> r[1] in r true julia> CartesianIndex(0) in r false ``` (cherry picked from commit 24b3273)
Currently, this hits a fallback method that assumes that division is defined for the elements of the range. After this, the following works: ```julia julia> r = StepRangeLen(CartesianIndex(1), CartesianIndex(1), 3); julia> r[1] in r true julia> CartesianIndex(0) in r false ``` (cherry picked from commit 24b3273)
Test doesn't pass backported
|
This reverts commit 304847e.
Currently, this hits a fallback method that assumes that division is defined for the elements of the range. After this, the following works: