Tried it out. As a single DICEN not apparently because the GNDT won’t let me, but it could be done via several dicerolls. For example a DICE(10^63) could be rolled as three DICE(10^21), with the first one corresponding to the first 21 digits, the second one for digits 22 to 43 and a third for 44 to 63.

I don’t really see this as an issue.

@Cuddlebeam, that may result in a non-uniform distribution, which would give bias to the randomness.

There ought to be some sane upper bound. Basing it on the limits of the system seems sound. 

We’d need to ask Kevin about the GNDT source but I suspect a DICE(10^21) isn’t the distribution we think it is. If DICE(X) is ceil(X * U) where U is floating point uniform from [0,1], U probably doesn’t have the 10^21 levels of precision we want.

*Kevan. Sorry you got autocorrected, Kevan

So would 20 digits or less have the precision we want? What digits do have a reasonable distribution?

Yes: That some of the larger integer DICE most recently rolled are divisible by 4096 is likely not a concidence.

That yes was in response to my own comment. No, 20 digits is too many still.

I don’t think we can know for sure without Kevan’s knowledge. 9 digits are probably safe. Anything that gets to that point has gotta be just as game breaking as something at 21 digits.

I’d naively assume that it’s a double, so the largest number where we still have single integer precision would be 2^53, or about 10^15.

The source code is just an int(rand($sides)+1) in perl.

We should have a more logical upper bound.

Perl appears to have a 48-bit RNG, although any DICE close to 2^48 will still be notably non-uniform.

@Matt: ...How?

[PSS] What’s more logical than the limitations of the GNDT? In the context of being able to see each individual digit of a die result at least.

I think it’s fine