Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112722 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62902 invoked from network); 3 Jan 2021 11:11:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Jan 2021 11:11:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9B2E11804D3 for ; Sun, 3 Jan 2021 02:47:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wp160.webpack.hosteurope.de (wp160.webpack.hosteurope.de [80.237.132.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 3 Jan 2021 02:47:11 -0800 (PST) Received: from [2a02:8109:9d40:1d44:40b6:f5d3:c567:d46c] (helo=nas.fritz.box); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1kw0ui-0005v0-Vj; Sun, 03 Jan 2021 11:47:09 +0100 To: Go Kudo , internals@lists.php.net References: Message-ID: Date: Sun, 3 Jan 2021 11:47:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-bounce-key: webpack.hosteurope.de;marc@mabe.berlin;1609670832;e1f6c8ab; X-HE-SMSGID: 1kw0ui-0005v0-Vj Subject: Re: [PHP-DEV] Re: Improving PRNG implementation. From: marc@mabe.berlin (Marc) On 01.01.21 20:22, Go Kudo wrote: > Hi Marc, and sorry for the late reply. Email has been marked as spam... > >> I would expect the Random number generator to implement from Iterator > using an integer for current() value >> and providing utility functions (simple functions or methods of another > class) for shuffle, random array entry like this: > > Thank you very much. This suggestion makes sense and looks very structured. > > However, I feel that in the PHP world, this structuring is a bit too much. > Ease of use is very important in PHP. One important reason for a PRNGInterface is (at least how I understand it) to allow implementing PRNG algorithms in userland but there would be no performant way to use this for shuffle and friends that's why I think such functions should consume any PRNGInterface instead of building it directly into the PRNG class. -> If you really want these as PRNG methods - one possibility could be a Trait providing these methods but this is very exotic for core functionalities. Another thing with the proposed `next*` methods is * How to get the current value? retrieving the next value only seems to be out of sync with the current PHP way (Iterator, Generator) * `nextByte(int $length)` How much values does this consume? How much random bytes can be generated with one value (4 bytes, 8 bytes, platform dependent). Does this consume multiple values to generate 1 byte 4/8 times? * same for `nextDouble()` on 32 bit platforms * Btw. it should be called `nextFloat()` as there is no double type in PHP and the float type is equivalent to C double precision > > Nevertheless, I am satisfied with this proposal. I'd like to hear from > someone who is more familiar with the PHP context about the form of the > implementation. > > But, it may be faster to actually hold a vote to ask this question. I'm not > sure how much support this proposal has at this point, but do you think > it's worth a try? I'm don't have voting rights and I'm not very active in discussions so I would be better to get some reasonable thoughts from someone more involved. Cheers Marc > > > 2020年12月29日(火) 18:26 Marc : > >> Hi zeriyoshi, >> On 23.12.20 14:41, zeriyoshi wrote: >> >> Thanks tyson. >> >> >> This would also make it easier to use those generators in brand new >> >> algorithms that weren't in the ionitial RFC. >> >> (or in algorithms written by users in PHP) >> >> This suggestion seems to make sense. Maybe the RNG should only focus on >> generating random numbers and not anything else. >> However, the fact that array and string manipulation functions are no >> longer native to C may have a speed disadvantage. >> >> So I came up with the idea of minimizing the interface definition as RNG. >> >> ``` >> interface PRNGInterface >> { >> public function nextInt(?int $min = null, ?int $max = null): int; >> public function nextDouble(): double; // maybe, non-needed. >> public function nextByte(int $length): string; >> } >> ``` >> >> The methods for array and string operations are defined separately as >> interfaces that inherit from the interface. >> >> ``` >> interface RandomInterface extends PRNGInterface >> { >> public function shuffle(array &$array): bool; >> public function arrayRand(array $array, int $num = 1): int|string|array; >> public function strShuffle(string $string): string; >> } >> ``` >> >> This can be overly structured, but it will serve all purposes. >> >> Personally I feel the interfaces still looking a bit off to me. >> >> I would expect the Random number generator to implement from Iterator >> using an integer for `current()` value >> >> and providing utility functions (simple functions or methods of another >> class) for shuffle, random array entry like this: >> >> ```php >> >> interface RNG extends Iterator { >> public function rewind(); >> public function next(); >> public function current(): int; >> public function key(): int; >> public function valid(); >> } >> >> >> interface PRNG extends RNG { >> public function __current(int $seed); >> public function getSeed(): int; >> } >> >> class RNGUtil { >> public static function shuffleArray(int $randomNumber, array $arr): array; >> public static function randomArrayElement(int $randomNumber, array $arr): mixed; >> public static function between(int $randomNumber, int $min = PHP_INT_MIN, int $max = PHP_INT_MAX): int; >> public static function bytes(RNG $rng, int $length): string; >> } >> >> ``` >> >> >> Regards, >> Go Kudo >> >> >> 2020年12月23日(水) 0:40 tyson andre : >> >> >> 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 Javahttps://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 >> >>