On Tue, Jan 5, 2021 at 6:40 PM Go Kudo <zeriyo...@gmail.com> wrote:
> Thanks Nikita.
>
> Thanks for the input. This looks like a very smart solution.
> I've edited the RFC and added a new proposal as TypeC.
>
> https://wiki.php.net/rfc/object_scope_prng
>
In addition to the functions you already list, I'd add
function rng_bytes(RNGInterface $rng, int $length): string;
function rng_between(RNGInterface $rng, int $min, int $max): int;
Similar to your type B proposal.
Just to share another possibility, we could also modify existing functions
to optionally accept RNGInterface, like
shuffle(array &$array, ?RNGInterface $rng = null): bool;
However, I'm not sure this is better than adding a separate family of
functions.
> However, I have a couple of concerns. The first is that users will have to
> be careful with RNG instances (for better or worse, TypeA will not allow
> users to use unintended instances), and the second is that it will
> complicate the implementation of PHP functions.
>
What do you mean by "use unintended instances" here?
Regarding implementation complexity, yes, this version is a bit more
involved if we want to allow userland implementations of RNGInterface. To
be honest I don't particularly care about supporting userland (we could
also only allow it to be implemented internally), but I think it shouldn't
be too hard either.
> Also, given the current environment in which PHP runs, I think that random
> number generation in the 64bit range should be supported.
> How about including the `next64()` method in the interface?
>
This is generally the part I'm least sure about. I agree that it would be
good to leverage 64-bit numbers on systems that support them. On the other
hand, I also think that having a consistent random number stream between
32-bit and 64-bit systems may be important. For example, if you use this
functionality for predictable "randomness" in unit tests, then it would be
a problem if your library could only be tested on 32-bit or only on 64-bit.
As long as an API like rng_between($rng, $min, $max) is used, we can always
assemble two 32-bit values into a random number that is larger than 32-bit.
But of course, fetching a single 64-bit number is more efficient...
Nikita
> 2021年1月5日(火) 23:53 Nikita Popov <nikita....@gmail.com>:
>
>> On Thu, Dec 24, 2020 at 5:12 PM zeriyoshi <zeriyo...@gmail.com> wrote:
>>
>>> I updated the RFC draft and changed it to a proposal to bifurcate the
>>> interface.
>>>
>>> https://wiki.php.net/rfc/object_scope_prng
>>>
>>> At the same time, I was looking into the RNG problem in Swoole and found
>>> out that the problem was actually occurring.
>>>
>>> https://www.easyswoole.com/En/Other/random.html
>>>
>>> The above problem with Swoole is only for child processes and can be
>>> fixed
>>> by the user, but as mentioned above, I think it will become more serious
>>> as
>>> PHP becomes more complex in the future.
>>> I hadn't thought of this before, but we might want to consider
>>> deprecating
>>> existing state-dependent RNG functions.
>>>
>>> I am seeking feedback on this proposal in order to take the RFC to the
>>> next
>>> step.
>>> Thank you in advance.
>>>
>>> Regards,
>>> Go Kudo
>>>
>>
>> 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 <zeriyo...@gmail.com>:
>>>
>>> > Nice to meet you, internals.
>>> >
>>> > PHP 8.0 has been released. With the inclusion of JIT, PHP is about to
>>> be
>>> > extended beyond the web.
>>> >
>>> > So I'd like to make a few suggestions.
>>> >
>>> > First , PHP has the historical Mersenne Twister PRNG. However, this
>>> > implementation keeps its state in a global and cannot be handled as an
>>> > object like other languages (e.g. Java).
>>> >
>>> > So, I created a PHP Extension and proposed it to PECL.
>>> >
>>> > https://marc.info/?l=pecl-dev&m=160795415604102&w=2
>>> > https://github.com/zeriyoshi/php-ext-orng
>>> >
>>> > But, Then I looked at the mailing list archives and noticed that a
>>> similar
>>> > proposal had been made before.
>>> >
>>> > https://externals.io/message/98021#98130
>>> >
>>> > I feel that this suggestion is needed now to expand PHP beyond the web.
>>> >
>>> > Second suggestion is to stop using the Combined LCG as the default seed
>>> > value for each function.
>>> >
>>> > PHP's Combined LCG only uses PID (or ZTS Thread ID) and time as
>>> entropy.
>>> > https://github.com/php/php-src/blob/master/ext/standard/lcg.c#L72
>>> >
>>> > With the development of container technology, this problem seems to be
>>> > getting more serious. So I think we should use the random numbers
>>> provided
>>> > by the OS (getrandom on Linux) if available.
>>> >
>>> > I would like to hear your opinions.
>>> >
>>> > Regards
>>> > Go Kudo <zeriyo...@gmail.com>
>>> >
>>>
>>
