-
-
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 any
and all
interface consistent with map
#20181
Comments
or make dims a keyword argument for the array/region signatures... |
Functions have their own types, but any function can be defined to have arbitrarily many methods with any number of arguments. So saying that, for example, |
I the suggestion in this issue might come from a misunderstanding of the differences between a function and a method. |
great to see parameterizing using a dims keyword would make the interface inconsistent with title of this issue changed to reflect the desire to make |
any
and all
interface consistent with map
Not if we also switched to using a dims keyword for |
Wouldn't a keyword argument incur too large a penatly for |
changing @nalimilan it's not clear to me from the performance tips whether or not there is a penalty for keyword args. it says there is not if you call a function that has them with only positional args, but what if you call that same function with them? lastly, could someone please elaborate on why Function types and generic functions are like oil and water ? |
The best way to find out whether the penalty is significant is to do some benchmarking. |
See section 4.6 of https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf. |
I'm pretty strongly against this idea — that is, allowing We allow mapping a function at the same time only because there's a major optimization to be had… and it's an optimization that we don't have a good alternative for. In this case, there's no inherent reason why zipping shouldn't be as fast as a varargs. |
what is the "major optimization" with varargs in |
That's not a general rule for deciding what methods should be supported — it's just something that should be taken into account when deciding if we should combine two distinct and orthogonal operations into one method. But even then, my only was far too strong there. The existence of an optimization isn't the only thing to consider. I hope you'd agree that the primary purpose of It's not as obvious to me that |
my question still stands. what's the optimization with varargs in |
Allowing multiple arguments to |
I did this on a branch (kf/multiany for those interested, but not really in a usable state) because I thought I wanted it, but frankly I don't like it. The biggest question is what the truncation behavior should be if you pass multiple arguments of unequal length. E.g. All that to say, I don't like it, so here's a simpler design, I think:
and people can write
That's not too many extra characters and the behavior is quite clear (truncation) |
We defined |
i'm not sure whether it's better to ask this on Discourse, but has it been discussed to have
Function{N}
where N is the number of input arguments?my use case is that i'd like to make the interface to
any
andall
consistent with that ofmap
. currently, the predicate versions of the former can not take a variable number of iterables like the latter can. rather, you have to manuallyzip
them up. no big deal, but consistency is nice.the problem is that
any
andall
have methods which specialize on Arrays and regions. and so a simple change of the signature to end with a var arg gets confused when there are exactly two. a conceptually simple fix to this would be to dispatch on how many input args the predicate took.The text was updated successfully, but these errors were encountered: