Roku Developer Program

[kbenson]

Is there any way to seed the RNG? I'm looking for reproducible pseudo-random events. If not, can I register a request for RND to support a seed value passed as an optional second param?

This is so I can choose a "random" number when computing possible AI moves, and if the move is chosen the same "randomness" is used.

[destruk]

It's probably not quite as helpful, but you could have your web/content server do the random calculations for your app to ensure they are done as random as possible.
In a 'hats off' to Endless -
6.2 Rnd(0) As Float Rnd(range As Integer) As Integer
Generates a pseudo-random number using the current pseudo-random "seed number" (generated internally and not accessible to user).

This looks to be a limitation of Brigthtscript. You can still generate a random array of random numbers and pseudo randomly pick one of them from a sampling. Added complexity for little payoff though.

[RokuKevin]

Rnd() does internally seed the random number generator. There should be plenty of entropy there.... Have you noticed an issue?

--Kevin

[jbrave]

I think he wants a predictable stream of pseudo-random numbers.

@kbenson: plenty of algorithms online to roll your own, try this one:

http://en.wikipedia.org/wiki/Mersenne_twister

http://saluc.engr.uconn.edu/refs/crypto ... rsenne.pdf

[kbenson]

Yes, predictable is the goal here. That is, "reproducibly random".

The problem with rolling my own solution here is that this will be called often. When the hard AI is playing, it will be called at least once for every possibly move, and then once again for every possible move after that, for every AI turn.

Also, BrightScript doesn't support left/right shift operators, we ended up implementing some ourselves for a CRC function in KidPaint (in librokudev now), so I figure most algorithm implementations would be fairly slow...

As for calling out to our server, that's undesirable for a few reasons. First, as mentioned above, it will called very often. Second, this would place an external requirement on an an app that has no other external requirement.

[GandK-Geoff]

Implementing a really complex PRNG in Brightscript is indeed a recipe for slow. There is an old classic though that's quite fast, not (nearly) as statistically strong as the modern variants, but decent for this particular task I think, since the quality constraints are rather weak.

In The Art of Computer Programming, Knuth describes a simple algorithm that starts with an array of high-quality random numbers generated by a slow algorithm or by true entropy. Then the fast/weak algorithm simply adds two numbers chosen at particular points in the array, modulus the native word size, in order to get each successive number. It's a FSR (feedback shift register) algorithm of a sort, combining words instead of bits, and using addition rather than XOR as the core combining operation.

In any case, the total operation count to create a new output number are pretty small: two array lookups, one addition, one array store, and tracking 3 pointers or indexes into the array (three increment-and-MOD operations).

It's also amenable to amortizing function call overhead, because you can run it in a tight loop for as many iterations as there are elements in the array, and then you have that many new pseudorandom numbers just sitting in the array waiting to be used.

Note that the array tap locations and array length must be chosen carefully -- Knuth provides a list of configurations that don't quickly fall apart.

Note of course that you would NEVER use this algorithm where randomness quality is really important. But when the goal is simply to be fast and not really horrible quality-wise, my recollection is it works decently well.

[RokuMarkn]

If you want a reasonably fast RNG that doesn't need cryptographic strength, you could just write a linear congruential RNG in brightscript. It would be one multiply and one add, plus the function call overhead.

--Mark

[kbenson]

Okay, all those ideas, plus some sample code renojim forwarded me, will probably end up getting implemented and stored in librokudev (thanks to those who weighed in!). So... anyone who's interested in this, you can check out librokudev later for some implementations. I'll try to remember to follow up here after done.