-
-
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
end
is unsafe with user-defined getindex
#16104
Comments
Shouldn't it call |
@stevengj that's the case only for one-dimensional arrays IIRC |
It would be natural to extend it to call |
I can play around with a PR for that if it has a chance of going through |
Here is the relevant code in julia-syntax.scm. Replacing A complication is that it calls trailingsize for the last index in cases with 2 or more indices, so that you can do e.g. |
|
Isnt' this "generalized linear indexing", on the chopping block in 0.5, see #14770. |
@mlubin, you would still have to overload it because otherwise it will return trailingendof(A,n) = n == ndims(A) ? endof(A,n) : trailingsize(A,n) Good to hear that this "feature" is on the chopping block, though; we can then remove (So far, the only registered packages that use the unexported |
Will it be easier to fix this after #14770? |
@mlubin, no, I think the two can be done independently if you define |
How about we just lower to one function name in all cases? This moves the logic into a place where custom types can intercept it… and it decouples the last index from the size. You just need a three-argument function Cartesian indices still pose a problem: |
@mbauman, because the goal is to get rid of |
I believe this should be fixed (or be feasible to fix within an offset array package) via #25763. |
Ref jump-dev/JuMP.jl#730, it seems like there's no way to change the behavior of
end
translating tosize
when used within a multidimensional array, which means that it's unsafe to useend
to index into JuMP arrays which don't use 1-based indexing. Any hope of a solution to this?CC @joehuchette @IainNZ
(Thanks @yuyichao for the pointer)
The text was updated successfully, but these errors were encountered: