Randomness failing in IDE for random kind of value

Authoring Inform 7
1

Generating random numbers seems fine. But this:

"Cards" by Victor Gijsbers

Lab is a room.

Card is a kind of value. The cards are ace, king, queen, jack.

After looking:
	let i be 0;
	while i is less than 10:
		let n be a random card;
		say "[n] . ";
		increase i by 1.

Gives me the following results on rerunning it a few times:

queen . jack . jack . jack . king . ace . king . king . jack . queen .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . jack . king . jack . jack . ace . king . king . king . queen .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . jack . king . jack . jack . ace . king . king . king . queen .
queen . jack . king . jack . jack . ace . king . king . king . queen .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . jack . jack . jack . king . ace . king . king . jack . queen .

As you can see, it starts with ‘queen’ every single time. But even after that, it is far from random; if I’m not mistaken, there are only three different sequences among these. How is this possible? Can I do something about it?

This is Inform for Windows 10.1.2.20220830. I’m compiling to Glulx and I do not have “make random outcomes predictable when testing” turned on.

The problem seems not to happen for a release version, so maybe I shouldn’t be bothered, but it did influence some testing I was doing just now. :smiley:

1 Like
2

I think the same issue was identified by @drpeterbatesuk a while back. See Lack of randomness sometimes when compiling for Glulx (very long thread).

2 Likes
3

Thanks! I missed that.

4

Note that he does present a workaround at Lack of randomness sometimes when compiling for Glulx - #7 by drpeterbatesuk.

There’s also a stronger fix (depending on a BBA-award method that may become outlawed in later releases) at Lack of randomness sometimes when compiling for Glulx - #77 by drpeterbatesuk.

2 Likes
5

I can’t quite understand whether the problem affects games in their Released version or if it only concerns Inform 7 with the IDE, when the author is testing their game within the interface. The thread is very interesting and quite long, and I must admit I don’t fully understand half of it yet. Some parts are still too technical for me (or refer to developer habits and tools that I’m not familiar with).

6

OK understood now thanks your new post. Thank you @otistdog

7

Thank the Good Doctor! He hasn’t been around much lately, but his legacy lives on.

@Zed was in the mix, too. He might have some color commentary or his own fix to share. I was pretty much just an observer.

2 Likes
8

The problem was in the interpreters (Glulxe, Git, etc.) rather than the story file, so it affects both authors and players when they use an interpreter version from before that thread. New versions with improved RNGs have been released, so the problem won’t occur in the newest version of e.g. Gargoyle or Lectrote or Spatterlight. However, there hasn’t been a new release of the Inform IDE yet, so authors are in some sense more likely to run into the problem than players.

2 Likes
9

Understood, thank you very much for these additional information. Tell me, if the workaround code provided by Dr Peter Bates remains in the released version, is it a problem ? Should we remove it before releasing and/or use the “not for release” feature ?

10

I would not recommend using the second workaround that replaces random, even for testing. It’s not a complete solution on its own, and replacing the RNG entirely provides lots of opportunity for introducing a similar problem again (only now it’s storyfile-specific and can’t be addressed by patching the interpreters). It’s cool that it’s possible but I wouldn’t want to stake my game’s functionality on it when there’s an easier way.

The first workaround of “priming” the RNG at game start, shouldn’t cause much harm. It’s an unnecessary waste of time and electric power on new interpreters, but it may avoid a disappointing experience for some players who aren’t on the newest version. However, I would not add it “just in case”, only if the RNG problem is actually observable in the game in question. It also becomes less useful as time goes on and especially as new Inform versions get released, because eventually enough people will be using up-to-date interpreters that it’s not worth keeping the workaround in place.

However, this is is a judgement call - others may come to a different conclusion.

1 Like
11

Thanks for your reply. Since the player’s experience is what matters most here, placing the workaround in the “not for release” section seems ideal, which aligns with your point, as interpreters with newer versions are not affected by the bug. I haven’t really delved into interpreters yet; so far, I’ve tested Lectrote, skimmed through Vorple, and noticed that you can create a release with Parchment (which can be updated). The first workaround (the one I’m currently using) allows for testing the presence of the bug regardless of the chosen option. We could even consider an auto-test that activates the workaround only if the bug is detected. On second thought, that’s probably what I’ll do. Thanks again!

12

How do you intend to do that? It seems difficult.

13

Well, it may be naive, I would try this : by randomly drawing, at the start of the game, a series of numbers between 1 and 4 and comparing the resulting sequence with one of the four identified by Dr. Peter Bates:

(sequence 1) 3424412223

(sequence 2) 3214332411

(sequence 3) 3444212243

(sequence 4) 3234132431


I have manually tested, every test conveys to one of these sequences. I imagine that from 8 digits onwards, the probabilities become low enough to reasonably estimate that the interpreter is affected by the bug.

14

Something like this, that works in my IDE:

The prime the random number generator rule is listed after the seed random number generator rule in the startup rules.
The prime the random number generator rule is listed before the update chronological records rule in the startup rules.

This is the prime the random number generator rule:
	let Sequence01 be "3424412223";
	let Sequence02 be "3214332411";
	let Sequence03 be "3444212243";
	let Sequence04 be "3234132431";
	let Random1-4 be "[one of]1[or]2[or]3[or]4[purely at random]";
	let RandomSequence be "[Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4]";
	if ("[RandomSequence]" exactly matches the text "[Sequence01]") or ("[RandomSequence]" exactly matches the text "[Sequence02]") or ("[RandomSequence]" exactly matches the text "[Sequence03]") or ("[RandomSequence]" exactly matches the text "[Sequence04]"):
		say "RNG bug detected [line break]"; [for test purposes]
		let dummy be a number;
		repeat with n running from 1 to 100:
			now dummy is a random number between 1 and 4; [warm up the RNG for Git]
		let b be a random number between 1 and 32633; [a high prime number, but not so high as to cause a significant delay to start-up]
		repeat with n running from 1 to b:
			now dummy is a random number between 1 and 4; [range used here makes no difference]
1 Like
15

It’s not a bad idea but some comments in the old thread mention that Git and Glulxe (in certain configurations) have a similar problem, but different sets of possible sequences. From a quick glance through the thread I also can’t rule out it’ll vary by operating system or something. So I’d be worried that this approach only catches the particular flawed RNG in the IDE but not an equally-flawed RNG in the interpreters players are using. But perhaps it’s a decent middle ground between putting in way too much effort into it vs. not trying to mitigate the problem at all.

3 Likes
16

Thank you for noticing this information that I hadn’t been able to detect.

You are certainly right.

17

I can’t find an exact equivalent in the TADS’s EventList, but seems that the bug involuntarily gives a potentially convenient randomised list, with a fixed first element (useful in the case the player is informed of something, then reminded about that something)

This can be useful in dealing with the issue, bugs stemming from scrapped tentative features aren’t uncommon, I think


Best regards from Italy,
dott. Piergiorgio.