While looking through the reducer code and tests I came across some things potential issues.
Reducers have an initial value that defaults to T(). Does this make sense for reducers where the identity of the operator does not equal T(). For example doing a min reduce with integers over a set of positive numbers with a default constructed reducer would always result in 0 which is probably not desired and the cause may not be immediately obvious.
The reducer unit tests don't generate their test files via cmake.
The reducer unit tests don't test bitwise and/or reducers.
Some of the reducer unit tests for construction are disabled for gpu policies, don't we want to ensure a consistent interface?
Some of the reducer unit tests do different things for gpu policies, don't we want to ensure a consistent interface?
Some of the reducer unit tests use the reductions in forone which is not a supported context, it doesn't go through the same mechanisms that forall does like make_launch_body and it doesn't make a per thread copy of the lambda.
While looking through the reducer code and tests I came across some things potential issues.
T()
. Does this make sense for reducers where the identity of the operator does not equalT()
. For example doing a min reduce with integers over a set of positive numbers with a default constructed reducer would always result in0
which is probably not desired and the cause may not be immediately obvious.