On 12/14/22 23:55, Julian Brooks wrote:
Yes, I'm one of those...
then i think you should start setting an explicit seed right now.
the simplest way i've found to force the currently hardcoded seed (for the first instantiated random generater), is something like this:
- seed the random generator with 255406
- discard the first 3186 random numbers
like so: #N canvas 2082 640 533 344 12; #X msg 307 69 seed 255406; #X msg 327 123 3186; #X obj 327 148 until; #X obj 230 246 spigot; #X msg 307 174 1; #X obj 230 271 print; #X msg 202 166 bang; #X obj 307 94 t b b a b; #X msg 367 172 0; #X obj 230 221 random 100; #X obj 281 197 t a; #X obj 367 200 t f; #X text 311 45 reset; #X connect 0 0 7 0; #X connect 1 0 2 0; #X connect 2 0 10 0; #X connect 3 0 5 0; #X connect 4 0 11 0; #X connect 6 0 9 0; #X connect 7 0 4 0; #X connect 7 1 1 0; #X connect 7 2 10 0; #X connect 7 3 8 0; #X connect 8 0 11 0; #X connect 9 0 3 0; #X connect 10 0 9 0; #X connect 11 0 3 1;
[random] seems to rear its head now & then.
of course it loops. it's a pseudo random generator. however, i find that the underlying algorithm is somewhat perfect with regard to repetition (last time i checked, it required about 4294967295 iterations to repeat, which is pretty good for a 32bit integer number).
that's not to say that the distribution for small ranges as output by [random] might *not* be ideal.
My memory is that when asked on here, Miller was a little coy about the algo (when was highlighted on-list as an 'interesting' [non-standard] implementation:)
iirc, miller always claimed that he was just blindly hitting the number keys to generate large numbers.
i don't fully trust this statement for the actual random generator (given that it consumes all possible numbers before repeating), but for the seed generator this is somewhat plausible, as this one only takes 536870912 iterations to repeat itself (so the PRNG itself has an 8-times longer period)