-
-
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
Make region a keyword argument for dimension reducing methods #25501
Comments
We could use I'm fine with doing this, but then let's use keyword arguments for all similar functions ( |
💯 "Region" to me means something like |
Triage says 👍 . Should be applied to all relevant functions though. Issue of what name to use still somewhat up in the air. |
The steps are:
|
TensorFlow uses |
Methods which perform dimension reduction using this kind of API:
Interestingly, we seem to opt for the "region" terminology only for methods which map prior to reduction, and for those that don't we use "dims." ( To me, "dims" seems like the most obvious and immediately descriptive term, and it's consistent both with the names of the functions used underneath, i.e. I'm indifferent as to whether |
FWIW, Numpy also uses (Though I also like |
On the one hand, we now use
So we're a bit internally split on this terminology. Are these reduction region arguments more similar to what |
Given what |
i thought i was more or less decided here that we didn't want to support a variable number of iterators to |
I still think we should use a keyword argument for |
Well folks, we have a problem. I've implemented the change to reducing functions. Using
This may be because when a dimension is specified, it goes through the more general method Any ideas? Is this still feasible? I can put up a WIP PR with my current implementation, if that would be helpful for diagnostics. |
I've still catching up with all the keyword and compiler improvements, but I think you can get around this by immediately re-dispatching to a positional argument:
It's just a little deceiving since |
Right, that is what I'm doing:
|
|
Does EDIT: Ah, that's what #25835 is about. But is that the problem here or does that construct still fail? |
It does indeed solve the problem.
(Though interestingly, the inferred return type is no longer a |
Having been going through and implementing this, I'm actually not so sure I like it. It could be that I'm just used to writing things like Really multi-arg |
I think the issue is that in |
I agree that it does clarify the intent somewhat, but has there been any confusion about it in the past? Regarding "might support other kinds of arguments," isn't that just taken care of by multiple methods and dispatch? |
Not necessarily; it's not ideal to re-use the same argument slot for a totally different meaning. |
Losing the ability to concretely infer the return type for these pretty essential functions in global scope is pretty unfortunate. Though perhaps there's a way to get around that that I don't know how to do. |
It should be fairly easy to get that to infer; I believe all we need is a constant Bool from EDIT: This already works. |
What if instead of deprecating a positional dimension argument to a keyword argument, we go all-in on |
While I agree that would be a nice "orthogonalization" of APIs, I think this is far too common an operation on matrices to be made that much more clunky. Array reductions are kind of bread and butter when doing any numerical work. |
Agreed --- it would be great for |
Last I looked the one in JuliennedArrays is about as fast as it'll get (EDIT: short of being able to elide the |
Yes, I figured if we did go the |
Re-marking for triage since I no longer think we should do this after partially implementing it if we aren't going to use multi-arg |
Triage still mostly likes the keyword argument. |
I had been very hesitant to support this, but I'm now fully on board. Two points crystallized my opinion — documenting them here for posterity:
|
If we are thinking of merging julia> max([1,2,3], [2,1,3])
3-element Array{Int64,1}:
2
1
3 The behavior we would presumably want for a combined |
I agree that having both the names |
Would this apply also to method that shift data along some dimensions, rather than reducing it? For example, is the plan to have: circshift(v, 1, dims = 2) == circshift(v, (0, 1)) # if v is a 2-dimensional array Or the two issues are unrelated and |
I think they're unrelated, since |
If possible, I think we should make the
region
argument in the dimension reduction methods ofany
andall
a keyword argument.map
has an incredibly handy method for multiple iterators, e.g.map(<, a, b)
. Currentlyany(<, a, b)
will use the methodany(f, itr, region)
, but it would be great to be able to reclaimany(<, a, b)
to do what it looks like it should do. That would require makingregion
a keyword argument in 0.7 with a deprecation, and introducing the new method in 1.0.The downside to this is that we have to come up with a default value for
region
in order to use it as a keyword argument, and whenregion
isn't specified then we want it to dispatch to the simpler, short-circuiting method not based onmapreducedim
.A similar argument could be made for other functions withWe're doin' 'em all.mapreducedim
-based methods, such assum(f, A, region)
, but I mostly care aboutany
/all
for now.The text was updated successfully, but these errors were encountered: