art4711

3 ms·

1. 1.▲
   by art4711 12y ago

   Got pointed back here that there was another response. Sure. If you subtract 1 from [1,2) you will get 52 bit precision (or 23 for floats as your magical constant indicates). This means that the number just before 1.0 will not be picked, th
2. 2.▲
   by art4711 12y ago

   I'm sorry, but if you mean Makoto Matsumoto who seems to be the name mentioned in the SFMT library, that library is bogus. It generates numbers in [1,2) and then maps that to [0,1) by subtracting 1. This can be trivially shown to lose
3. 3.▲
   by art4711 12y ago

   You most certainly can. If you follow the github links in that blog post, you'll see in arbitrary_range.c that that's exactly what I do in "rd_positive". Pick the highest number in the range, calculate the distance to ne
4. 4.▲
   by art4711 12y ago

   I actually got the link to his code yesterday and it's eerily close to what I wrote a few months ago, but I rejected that approach because I didn't like that any of the numbers in [0.5,1.0) were so much more likely to be returned
5. 5.▲
   by art4711 12y ago

   Author of the blog post following the sudden surge of traffic here. > Producing quality random floating point numbers, fast, is a solved problem Is it? Do you have any reference I can read? Everything I've found is obviously flawed