random in Glulx doesn't match DM4

[curiousdannii]

The Glulx I6 implementation of random does not match the behaviour described in the DM4. Instead of negative or zero values seeding the interpreter's RNG, it is passed directly to the Glulx @random opcode, before adding 1. This results in the following inconsistencies:

Argument	DM4/Z-Machine	Glulx
Positive N	Return a random number in the range 1 to N	Return a random number in the range 1 to N
Zero	Switch the interpreter RNG to random mode	Return a full 32-bit random number
Negative N	Seed the interpreter RNG in predictable mode	Return a random number in the range (N + 2) to 1

Nobody would intentionally call random(-10) expecting it to return a number between -8 and 1. If Glulx's random was returning useful results then it could be argued that it should be left as is, but considering how bad those results are, it should probably just be fixed to match the DM4.

[erkyrath]

Yeah, this is fair. The I6 definition of random() is pretty silly but the current Glulx behavior is definitely worse.

Only question is, should random(-1) do @setrandom 1 or @setrandom $FFFFFFFF? I realize this isn't a very important question...

[curiousdannii]

I'd say @setrandom $FFFFFFFF as it will be simpler: the zero and negative cases wouldn't need to be distinguished, it can just pass the arg across.

[erkyrath]

The I6 definition of random() is pretty silly

Of course, it is the Z-machine definition of @random that is silly here. The I6 function (called with one argument) simply invokes @random directly. I copied this behavior in the Glulx code, adding one for consistency in the positive case, but I didn't think about the zero or negative cases. Oops.