Improving PRNG implementation.

On Wed, Dec 16, 2020 at 4:56 PM Sara Golemon <pollita@php.net> wrote:

I expect the main use-case is generation of predictable random numbers based on a seed, in a way that does not rely on global state. mt_srand() + mt_rand() provide the basic functionality, but because they are using global state, any other library that also happens to use mt_rand() somewhere will screw up your seed sequence. You need to implement your own PRNG in userland, which will be slower (esp. as RNGs usually require wrapping math, which is not efficiently supported in PHP). Additionally, if you want to perform something like an array_rand() based on your independent RNG stream, there's no way you can do that efficiently (as you don't have random access into the underlying data array). As such, I do like the idea of providing this functionality, as it falls squarely in the area of "performance sensitive and hard to implement in userland", which is exactly the kind of functionality we can justify having in the standard library. (The abstract functionality, no comment on the particular implementation used here.) Regards, Nikita

On Wed, Dec 16, 2020 at 4:56 PM Sara Golemon <pollita@php.net> wrote:

take it as constructive feedback. OK, You're welcome. And sorry for replying directly to you by mistake.

expanded API for producing a reliably predictable series of numbers based on more finely tunable seeds? Iterable PRNG generator? Object scope PRNGs are useful when consistency of the result with respect to the seed value is required For example, the following code will result in unintended behavior if the generated values are required to be consistent. \mt_srand(1234); foo(); \mt_rand() === 411284887; // false function foo() { \mt_rand(); // code added } They also have the added benefit of being serializable. Being able to serialize the state allows us to take advantage of the PRNG's random periods.

I'm talking about the call to the php_combined_lcg() function inside PHP. This is still in use today for various purposes such as Meresenne Twister initial seeding, sessions, etc.

popularity/use. With all due respect, this repo is less than two weeks old and has 8 stars. Who needs this and why is it not services by the PRNG and CSPRNG options already available? I am not planning to bundle this implementation into the core, and I think that would require a deeper discussion in the RFC. I plan to implement it in full scratch according to the results.

On 19.12.2020 at 07:33, zeriyoshi wrote:

RFC karma granted. Best of luck with the RFC! :) Christoph

Hi Go Kudo, **A possible alternative that is widely used in other programming languages is to limit the interface API to only generating bytes/integers,** and to provide global functions that would use generic random number generator objects (from internal or user-provided code) in their algorithms. This would also make it easier to use those generators in brand new algorithms that weren't in the initial RFC. (or in algorithms written by users in PHP) This alternative is similar to Java https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#shuffle(java.util.List,%20java.util.Random) and https://docs.oracle.com/javase/7/docs/api/java/util/Random.html and C++ https://www.cplusplus.com/reference/algorithm/shuffle/ where the algorithms accept a random number generator conforming to some interface and Python https://docs.python.org/3/library/random.html#random.shuffle ``` interface PRNGInterface { public function random[Signed]Int(): int; // between PHP_INT_MIN and PHP_INT_MAX (4 bytes or 8 bytes) public function randomBytes(int $length): string // $length bytes of raw data // possibly randomByte(): int // between 0 and 255 // public function randomIntInRange(int $min, int $max) // __serialize(), __unserialize() may be provided, but may be counterproductive for classes that wrap /dev/urandom or random_bytes()? } // possibly provide a trait that provides defaults based on abstract function randomInt function whateverprefixornamespace_rand(PRNGInterface $rng, [int $min, int $max]): int {} // If this is intended to be secure, whateverprefix_array_rand may need to avoid the optimizations used by array_rand for sparse arrays function whateverprefixornamespace_array_rand(PRNGInterface $rng, array $array, ...): int {} function whateverprefixornamespace_shuffle(PRNGInterface $rng, array &$array): bool; // alternately might be possible by extending existing global functions with an optional parameter ``` Thanks, - Tyson

On Thu, Dec 24, 2020 at 5:12 PM zeriyoshi <zeriyoshi@gmail.com> wrote:

I think the general direction of your second proposal (B) is the right one, but I'm concerned about some of the details. First and foremost, I don't think that RNG should extend Iterator. Just having a single "next()" method or similar is sufficient. The Iterator interface provides many additional things that don't really make sense in this context and only complicate the implementation. We should clearly specify the value range of next() though. I assume that for portability reasons (ensure same sequence on 32-bit and 64-bit) this would have to be a sign-extended 32-bit value. The type B proposal distinguishes between a RNG and a PRNG interface. Is this really useful? I don't think the value of the "getSeed()" method is high enough to justify the split interface. The RNGUtil class has methods like: public static function shuffleArray(int $randomNumber, array $arr): array; This doesn't make sense to me, as a single random number is not enough to shuffle a whole array :) Instead this should be accepting the RNG and perform an internal call to next() (of course, with a fast by-pass mechanism if the RNG is implemented internally): public static function shuffleArray(RNG $rng, array $arr): array; I'm also wondering why this is a static class rather than a set of free-standing functions. Why RNGUtil::shuffleArray() rather than rng_shuffle_array()? Regards, Nikita 2020年12月16日(水) 23:46 zeriyoshi <zeriyoshi@gmail.com>: