Has anyone done any tests to see how consistently random Inform’s random choices are? I’ve been testing a function using the “if a random chance of 1 in 10 succeeds” construction, and it’s continuing to skew high - much closer to 20% than 10% success.
It is absolutely possible that I’m just getting a weird distribution, and my experimental tests average out about right, but has anyone done any large-scale data collection? What about random distribution to prevent bunching? How is Inform’s “random” put together, anyway?
I didn’t spend much time on it, but put together the extremely simple test listed below.
I ran it about twenty times and found that the variation was a bit odd in that 1 and 2 seemed to get about 1/2 of the total distribution versus the 1/3 they should have. Statistically speaking, there were enough tests to make that relevant, though the test isn’t a particularly thorough one beyond just pulling numbers.
There’d be straightforward ways of making this test more useful. Not knowing anything about inform’s internals, I’d start out assuming that it isn’t inform, as such, that generates the random numbers but the interpreter itself being handed the “get me a random value” request, so a test like this would be more helpful tested across multiple clients and OSs.
In practice, I use random pretty regularly and haven’t noticed the distribution being off enough to bother me (or even notice until your post), but if you’re doing something that’s more sensitive to an accurate distribution it would be a bigger deal.
n1, n2, n3, n4, n5, n6 are numbers that vary.
x is a number that varies. X is 0;
When play begins:
while x < 100:
Let y be a random number from 1 to 6;
increase x by 1;
if y is 1:
increase n1 by 1;
if y is 2:
increase n2 by 2;
if y is 3:
increase n3 by 1;
if y is 4:
increase n4 by 1;
if y is 5:
increase n5 by 1;
if y is 6:
increase n6 by 1;
Say "Roll distribution:[line break]";
say "1: [n1], 2: [n2], 3: [n3], 4: [n4], 5: [n5], 6: [n6]";
The test room is a room.
I get pretty much the same kind of result: n2 is consistently higher than the other values (though not always a great deal higher).
I also checked whether the bias was consistent from turn to turn by changing your code to an every turn rule. Same result. Then I added a seventh value, to see whether it was an artifact of choosing six values. Nope – 2 is always selected more often than the others.
This may be an item for a feature request rather than strictly a bug. Not sure.
It could be a bug. I’m reminded of when I tried to implement Fortune in Perl - I discovered that the Mac stored addresses in the fortune files differently from other *NIX machines (I think they were four-byte addresses instead of two bytes, and there may have been a byte order issue too). The result was that only half of the fortunes were ever chosen. Either it was all even-numbered, or only the first half of the fortune file - I can’t remember.
Another 1.000.000 tries using the Gnome Linux IDE:
And using only 2 values:
So that’s looking pretty good. I also tested whether there was any correlation between the nth and (n+1)th result, but again that doesn’t seem to be the case.