Mr STL explained why that (and other rand()
related constructs) are a very bad idea in his presentation "rand() considered harmful".
The idea behind that code is to use floating point to reduce the entropy loss of a random number clamped by a modulo operation.
As Stephen points out, the floating point solution has not the problem which the modulo operation introduces (Basically there is an interval of values which have more probability to be generated than the others, thanks to the modulo, breacking the theorical uniformity of rand()
).
But floating-point introduces a new problem: The rounding produced at the final conversion from float type to the integral type the user expects leads to the problem that the same number is generated many times for different inputs, but a few values are generated only by one. So, again, the uniformity is lost.
Of course that rounding is not a problem if the goal is to generate a random floating-point, as in your case. But the roundings and divisions performed could lead to break the uniformity of the distribution too.
The conclusion to all of the menctioned above is: That code tries to solve the uniformity problems of the classic modulo way, but leads to (less? I'm not sure) uniformity problems too. So try to replace C random facilities with other libraries (Like the standard <random>
library provided since C++11).