Correct, in the version of rand.s at the HEAD on GitHub. Byte 0 feeds into future values of bytes 1 and 2, but byte 3 doesn't feed into anything. A corrected version of this subroutine would use byte 3 in some capacity to form the output.DRW wrote:Aren't the four bytes of the seed just there to calculate the next seed?tepples wrote:In current rand.s, X contains byte 2 AND $7F, A contains byte 1, and byte 3 (the high byte) never affects the state. A corrected version might have X contain byte 3 AND $7F and A contain byte 2, so that the resulting sequence is less predictable. Or if you're going to rename it, you can just load byte 3 into A and zero out X.
I mean, the seed is four bytes while the return value is two bytes. So, two of them go unused anyway when it comes to the return value.
Or do you mean that byte 3 not even influences the calculation of the next seed and is totally useless?
Correct.DRW wrote:But doesn't that mean that, when I use the original rand() function and I only need a value from 0 to 255 and I use it like this:rainwarrior wrote:rand+1 is of lower quality than rand+3.
rand() & 0xFF
that this would be bad since I only use the not so good bits?
In theory, each LCG is characterized by three numbers: the modulus (in this case 2^31 or 2^32 for the 31/32-bit version or 2^23 or 2^24 for the 23/24 bit version), the multiplier (in this case 0x01010101 = 16843009 for the 31/32-bit version or 0x010101 = 65793 for the 24-bit version), and the addend (in this case 0x31415927 = 826366247 for the 31/32 bit version or 0x415927 = 4282663 for the 24-bit version). As I understand it, the standard form of specifying an LCG is with the multiplier and addend expressed in base 10 (decimal) rather than base 16 (hexadecimal).Why does the corrected version in this thread look so totally different with an additional variable called rand_addend and the value 4282663? Is this all necessary or is there a minimum fix that changes the randomizer back to 32 bit, but with only small changes in the code?
rainwarrior: DRW is referring to my suggested optimized version, not the corrected version. The optimized version has the same behavior as the current rand.s but doesn't calculate the otherwise unused byte 3 at all.