BaseDigitExtractor< KeyT > Struct Template Reference#
hipcub::BaseDigitExtractor< KeyT > Struct Template Reference
Base struct for digit extractor. Contains common code to provide special handling for floating-point -0.0. More...
#include <radix_rank_sort_operations.hpp>
Inheritance diagram for hipcub::BaseDigitExtractor< KeyT >:
![](structhipcub_1_1BaseDigitExtractor.png)
Public Types | |
enum | { FLOAT_KEY = TraitsT::CATEGORY == FLOATING_POINT } |
typedef Traits< KeyT > | TraitsT |
typedef TraitsT::UnsignedBits | UnsignedBits |
Static Public Member Functions | |
static __device__ __forceinline__ UnsignedBits | ProcessFloatMinusZero (UnsignedBits key) |
Detailed Description
template<typename KeyT>
struct hipcub::BaseDigitExtractor< KeyT >
Base struct for digit extractor. Contains common code to provide special handling for floating-point -0.0.
- Note
- This handles correctly both the case when the keys are bitwise-complemented after twiddling for descending sort (in onesweep) as well as when the keys are not bit-negated, but the implementation handles descending sort separately (in other implementations in CUB). Twiddling alone maps -0.0f to 0x7fffffff and +0.0f to 0x80000000 for float, which are subsequent bit patterns and bitwise complements of each other. For onesweep, both -0.0f and +0.0f are mapped to the bit pattern of +0.0f (0x80000000) for ascending sort, and to the pattern of -0.0f (0x7fffffff) for descending sort. For all other sorting implementations in CUB, both are always mapped to +0.0f. Since bit patterns for both -0.0f and +0.0f are next to each other and only one of them is used, the sorting works correctly. For double, the same applies, but with 64-bit patterns.
The documentation for this struct was generated from the following file:
- /home/docs/checkouts/readthedocs.org/user_builds/advanced-micro-devices-hipcub/checkouts/docs-5.5.1/hipcub/include/hipcub/backend/rocprim/block/radix_rank_sort_operations.hpp