-
-
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
Deprecate dims methods for iterator forms? #35292
Comments
I think using
I proposed to add yet another lazy object type to solve these problems: #16606 (comment). See also #33130. |
Bullet 2 points towards We could have variants which don't drop dimensions. StarSlice.jl is a sketch of this, writing Also ref EachSlice types of #32310, where I thought the point was to pretend you were passing in slices, while e.g. Distances.jl can still compute efficiently on the whole array. |
Thanks, that's a good point (my understating is that we can still keep array-of-arrays interface). I guess we can also make something like
I don't think this is required to be implemented from the get-go but I think (eventually) making things like |
On the other hand it is equivalent to |
It seems like the
dims
-based methods could be from another time. It seems that we now have a way to do this using iterators:Could we make our APIs simpler by dropping the
dims
-based versions and instead just requiring that the user uses an appropriate iterator before the call? One thing that would have to be true when doing this is that it should be just as efficient, so I wonder if @maleadt could comment on whether there's any extra optimizations on things like GPUs that are available insum(A,dims=2)
vssum(eachcol(A))
. Otherwise, it might be interesting to drop in a Julia 2.0?(One note is that we'd need iterators on higher dimensions as well, though that could be done)
The text was updated successfully, but these errors were encountered: