[BUG] next_float and next_double return values in range [0,1]

[ChuckHastings]

Describe the bug
The code that implements next_float and next_double that occurs here:

raft/cpp/include/raft/random/detail/rng_device.cuh

Line 491 in 401935b

DI float next_float()

can generate the value 0 (when val is 0) and the value 1. The value 1 is more subtle, but occurs when the floating point representation of val and the floating point representation of (1U << 24) or (1LU << 53) [for doubles] are equivalent.

The consequence of this is that usual assumptions about using random floating point values to compute with are violated.

Note that #493 includes some discussion on this item. I suspect the issue is worse than just a discrepancy between Philox and PCG.

Steps/Code to reproduce bug
I was able to reproduce the error in a simple CUDA program to that converted

uint32_t num_u{0xffffff};
uint32_t denom_u{0x1000000};

to floating point values and computed the division, and the corresponding uint64_t values the same way.

Expected behavior
The standard is for floating point values to be uniformly distributed between [0, 1).

Environment details (please complete the following information):
Should fail on all. I tested on this configuration:

• Environment location: Bare-metal
• Method of RAFT install: conda

Additional context
Seems like directly constructing the bit pattern for the floating point value might be better than relying on division.

[ChuckHastings]

https://mina86.com/2016/random-reals/ does a nice job of explaining the flaw and suggests a bit-masking solution to creating the value.