You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 21, 2024. It is now read-only.
Will cub support using more generic scan_op such as T1 operator()(T1 &a, T2 &b) ? The use case is to scan on an array of structs and calculate based on structs' members.
Is there any suggestion on implementing such a primitive?
The text was updated successfully, but these errors were encountered:
I believe that your case will be addressed by the following PR. After the PR is merged, function object return type will be selected as an accumulator type. So you'll be able to pass the mentioned scan_op.
Is there any suggestion on implementing such a primitive?
A common pattern to resolve the situation you are describing is to use a cub::TransformInputIterator and/or thrust::transform_output_iterator. If you're able to provide more details of what exactly you're trying to achieve, we may be able to assess whether that could work in your case and provide more guidance on how the iterators could be applied.
Closing as @elstehle's answer will work currently, and @senior-zero covered a future improvement in this area. Let us know if you have any other questions about this.
Will cub support using more generic scan_op such as
T1 operator()(T1 &a, T2 &b)
? The use case is to scan on an array of structs and calculate based on structs' members.Is there any suggestion on implementing such a primitive?
The text was updated successfully, but these errors were encountered: