-
Notifications
You must be signed in to change notification settings - Fork 18
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
semantics of functions based on reduce #290
Comments
We will analyze this issue in detail for v0.3 and extend and harmonize the interface. |
After discussion we plan to take the following actions. 1.- Guarantee that current support of reductions is restricted to homogeneous reductions. |
I am fine with the 4 points proposed, but I think that the 2 most useful semantics (those provided by
They correspond to variants 1-2 and 3-4, respectively, in: |
What you mention as 1 (std::reduce with no value) it is not specified the reduction of just the elements. In fact a call to About the issue about using initial value instead of identity we defer this discussion to issue #343, Consequently, we keep this issue closed. Discussion about using identitiy value or initial value will go on at issue #343. |
Sorry I missed the specification of 1 in terms of 3. Then better to be consistent with plain C++. As just a note, this semantics looks a bit strange for someone used to functional programming (that is where However, this discussion is probably out of scope here, better to stay with the current C++ way. |
I think some consistency is missing in the semantics of the operators including a reduce operation:
reduce
,stream_reduce
andmap_reduce
. I suggest to choose one of the reduce semantics that have been proposed in literature and use it consistently.In general, I would avoid allowing user functions with "non-homogeneous" signature: U x T -> T, since this forces the reduce to be implemented sequentially. I suggest to stay with the simpler user function signature: T x T -> T and require it is both associative and commutative, as already done.
I can point out at least three variants of the reduce semantics:
From my understanding, I would say currently the third variant is used (which seems the must cumbersome to me), and the non-homogeneous user function is supported (for which only the sequential implementation is correct). I would suggest to opt for either first or second variant and support only homogeneous user functions, that is also what is supported by
std::reduce
.The text was updated successfully, but these errors were encountered: