well, the reason why we added the doc id is to have better support for consistent pagination, so it guarantees consistent random number generation on a consistent point of view over the indexes.

But, if you are allowing multiple indexes to invoke it, then isn't it going
to inherently be inconsistent because you will possibly not pick up where
you left off, thereby restarting further down the seed?

Personally, I think that having only the seed gives it a more consistent
flow, and the introducing the docBase + docId just adds the potential for
a strong bias in the case of 0, which must be substituted somehow, and
incidental bias thereafter, generally increasing as the sum grows as it
increases the likelyhood that the nextFloat's former xor operation (rand ^ seed) will have a much larger or much smaller number given a seed with
similar bits. I definitely noticed this behavior while adding the unit
tests, which led me to my current "fix".

On Tue, Apr 1, 2014 at 6:51 AM, uboness notifications@github.com wrote:

well, the reason why we added the doc id is to have better support for
consistent pagination, so it guarantees consistent random number generation
on a consistent point of view over the indexes.

Reply to this email directly or view it on GitHubhttps://github.com//pull/5613#issuecomment-39192401
.

Thinking it through some more, the docId does provide something if two indexes invoke it at the same time since there is no synchronization of the seed update (thus returning the same value for them both without it). However, as long as they are separate invocations, then it's still a random result to both (ironically even if it repeats for one of them) without it, and I am still not convinced that the bias of the docId is superior.

Of course, I am not an expert on random number theory, so take that with a grain of salt.

yes, the idea initially was the be consistent with pagination across indices (where the starts at 0 for each index). But thinking about it more, indeed there are too many "if"s here... we can remove the id and stick to the normal PRNG implementation, and who ever wants consistent pagination can just use seed+scroll.

btw, the seed is already biased here as the original seed that the user sends (or the default current time millis) is merged with the shard id (which is a must so each shard will generate different random number per doc)

I'll work on your PR, thx!

Works for me. The shard id modification of the seed makes perfect sense because otherwise there will be "unexpected" collisions within the merged results.

@uboness I labeled this issue and assigned it to you - please feel free to re-label

thx @s1monw