A dice rolling program is only as good as the worst of:
- the random number return to die-sides algorithm
- the pseudo-random seed generator
Most are close enough to be better than dice.
Since computers can not generate truly random numbers, no die roller is truly random. The pseudorandom numbers, however can be sufficiently random enough to be more random than real dice.
A recent study found that most commercial d6 are biased significantly. The study had some flaws, but generally showed a bias for low numbers on most commercially produced d6's. (In one company's run, almost to the point of 1's being 2/7 of 1d6 rolls!) No individual batch tested showed a truly even distribution.
Some technical details...
There are two methods of random number return used in programming:
- A fractional return on a float or double-float (double). EG: 0.348826495
- A whole number return on an int or double-int (long). eg: 25565
given a fractional, the norm is to multiply the sides by the returned fraction, giving a fractional number between 0 and sides; round that down, getting an integer from 0 to sides-1, inclusive; then add 1, to get an integer from 1 to sides, inclusive. Due to both the nature of the fractions, has a slight bias, but it's effectively below resolution, on 16 bit machines. On some 8 bit machines using single precision, it has a notable bias on larger die types. The use of rounding routines also can affect this; the most common is a truncation, which is mathematically acceptable. §
Given an integer return, the normal mode is to perform a modulus operation (in American: find the remainder). Then add 1. 1+ ( Return modulus sides ). This introduces a very slight bias except for d4, d8, and d16. That bias is for LOW numbers, and is (maximum_return mod sides) / maximum_return. On 8 bit machines, with single precision integer returns, that's (256 mod sides)/256, for 0 for d4, d8, and d16, 1/64 for d6 and d10, 3/128 for d10, and 1/16 on d20. It's 7/32 for d100... on a 16 bit machine, with a long return (32bit integer), it's negligible for all dice below 10000 sides...
But, without looking at sources, the methods and return values can't be fairly evaluated.
The random number generation, however, varies WIDELY by OS, random number generation algorithm used, the random number seeding method, and even programming language used.
On newer machines with 16bit architectures, the skew is usually low, and slight. On 32bit machines, the skew is usually low, and miniscule. As long as you're using one for a 16 bit or newer machine, you should be as random as dice, if not more random.
§ the specification for the applesoft floating point routines written by Wozniak is for a 3 byte and 5 byte, using a single exponent byte, and 2 or 4 byte mantissa.
A typical (IEEE compliant) float these days is 4 bytes long, using a 24 bit signed mantissa (for ±2^23) range and an 8 bit exponent. As decimals output, the limit of precision is about 6 places. A double (double precision floating point) is 4 bytes, 53 signed mantissa and 11 exponent. Quadruple Precision is 8 bytes long with a 113 bit signed mantissa and 15 bit exponent, reliably giving 30+ place decimal accuracy. Note that in all three, the sign bit leads, then the exponent, then the mantissa. Quads are not routinely available yet.