I’ve been trying to get my head around a curiosity which I had noticed before: when compiling for Glulx, even when the random number generator should be non-deterministic it sometimes is not.

Experimenting further, this seems to be the case when repeatedly calling the random number generator for a range between 1 and 2^n, in which instance the numbers generated seem to always follow one of 2^n distinct but reproducible sequences.

e.g.

```
"Testing_Choosing_A_Random_Number" by PB
Lab is a room.
The File of PseudoRandom Results is called "PseudoRandomResults".
To say choose the password: say "[one of]Cappuccino[or]Americano[or]Latte[or]Flat White[purely at random]".
Password is a text that varies.
When play begins:
if the The File of PseudoRandom Results exists:
read the File of PseudoRandom Results into Table of PseudoRandom Results;
let t be a pseudorandom sequence of 10 up to 4;
if there is a randnumber of t in the Table of PseudoRandom Results:
choose row with randnumber of t in Table of PseudoRandom Results;
now the count entry is the count entry + 1;
otherwise:
choose a blank row in the Table of PseudoRandom Results;
now the randnumber entry is t;
now the count entry is 1;
write the File Of PseudoRandom Results from the Table of PseudoRandom Results;
showme the contents of the Table of PseudoRandom Results;
To decide which text is a pseudorandom sequence of (q - a number) up to (n - a number):
let t be "";
repeat with s running from 1 to q:
let r be a random number from 1 to n;
now t is the substituted form of "[t][r]";
decide on t.
Table of PseudoRandom Results
randnumber (text) count (number)
with 16 blank rows
```

leads (after 51 runs) to output like:

Table of PseudoRandom Results

(row 1) | 3234132431 | 16 |

(row 2) | 3424412223 | 12 |

(row 3) | 3214332411 | 12 |

(row 4) | 3444212243 | 11 |

(row 5) | – –

(row 6) | – –

(row 7) | – –

(row 8) | – –

(row 9) | – –

(row 10) | – –

(row 11) | – –

(row 12) | – –

(row 13) | – –

(row 14) | – –

(row 15) | – –

(row 16) | – –

i.e. despite each digit being in theory independently randomly generated, in fact they only appear (randomly) in one of 4 distinct sequences each time the story file is opened- and, unhelpfully, the first in the sequence is always 3. Meaning that if during ‘When play begins…’ we are randomly choosing one of 4 passswords, e.g.

```
To say choose the password: say "[one of]Cappuccino[or]Americano[or]Latte[or]Flat White[purely at random]".
```

we always get the third password (shown here after 20 runs of the story):

Table of PseudoRandom Results

(row 1) | Latte | 20 |

(row 2) | – –

(row 3) | – –

(row 4) | – –

This happens in similar fashion if there are 8 alternatives, when there are 8 possible sequences and the first result is also always 3 or 7:

Table of PseudoRandom Results

(row 1) | 3618732415 | 5 |

(row 2) | 7468452663 | 8 |

(row 3) | 7428852623 | 7 |

(row 4) | 3658332455 | 8 |

(row 5) | 3238172831 | 4 |

(row 6) | 7888612287 | 8 |

(row 7) | 7848212247 | 5 |

(row 8) | 3278572871 | 5 |

(row 9) | – –

(row 10) | – –

or with 16 alternatives, when there are 16 possible sequences and the first result is always 03, 07, 11 or 15:

Table of PseudoRandom Results

(row 1) | 07080816140102021615 | 17 |

(row 2) | 03060116151110040113 | 11 |

(row 3) | 15121416041302140603 | 7 |

(row 4) | 07081616060102020815 | 12 |

(row 5) | 03060916071110040913 | 7 |

(row 6) | 11021116091510081109 | 12 |

(row 7) | 11100716050710160701 | 13 |

(row 8) | 07160416100902101207 | 8 |

(row 9) | 15120616121302141403 | 11 |

(row 10) | 11101516130710161501 | 13 |

(row 11) | 03141316110310121305 | 11 |

(row 12) | 15040216080502061011 | 10 |

(row 13) | 03140516030310120505 | 11 |

(row 14) | 15041016160502060211 | 5 |

(row 15) | 11020316011510080309 | 8 |

(row 16) | 07161216020902100407 | 2 |

or with 2 alternatives, when there are only 2 possible sequences, both starting with 1, 2

Table of PseudoRandom Results

(row 1) | 1222212221 | 19 |

(row 2) | 1212112211 | 18 |

(row 3) | – –

(row 4) | – –

As I understand it, the random number generator is provided by the interpreter, and the interpreter may depend on an OS function, so others’ mileage may vary. I get similar results with both Glulxe and Git on a Windows 10 laptop in the Windows IDE, and directly running Windows Glulxe 0.6.0 (Windows Glk 1.52) but I see it in Lectrote 1.4.5 only with Git- not with Glulxe or Quixe.

This code as written runs with 6M62, but I see same phenomenon with 10.1.2. This behaviour is not seen when compiling for Z-machine.

@zarf , any thoughts? What is behind this observation, and what is the best way to circumvent it while using the IDE?

EDIT: code fixed to work around a bug preventing compilation in Ver 10.1.2