Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112777
MIME-Version: 1.0
References: <CABTDVhA-FvEXdS+A=T5bJnX5YxjseN+ko14GUOqnuA52-omiiw@mail.gmail.com>
 <CABTDVhAYjCiZKGPJw6nMVHYp6wmVeqFzE+bK2Q3WzXW=9EV7ew@mail.gmail.com>
 <CAF+90c9j5yYtHvjHZjF5jyGA=zqiyPxcGuWh2EEo=LuwK3CzgQ@mail.gmail.com> <CABTDVhDAKu19iLmYx5n9st2b_vWNjBPcPtt+hwoxeg4r0xY3Gg@mail.gmail.com>
In-Reply-To: <CABTDVhDAKu19iLmYx5n9st2b_vWNjBPcPtt+hwoxeg4r0xY3Gg@mail.gmail.com>
Date: Wed, 6 Jan 2021 11:50:33 +0100
Message-ID: <CAF+90c9Yf8S_JvOhVPw0SoN=tL44-hi3gUwdNTSbavX++QzLRA@mail.gmail.com>
To: Go Kudo <zeriyoshi@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a42f4c05b8391897"
Subject: Re: [PHP-DEV] Re: Improving PRNG implementation.
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a42f4c05b8391897
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 5, 2021 at 6:40 PM Go Kudo <zeriyoshi@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 =3D 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 t=
o
> 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 rando=
m
> 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=E5=B9=B41=E6=9C=885=E6=97=A5(=E7=81=AB) 23:53 Nikita Popov <nikita.p=
pv@gmail.com>:
>
>> On Thu, Dec 24, 2020 at 5:12 PM zeriyoshi <zeriyoshi@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 foun=
d
>>> 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 seriou=
s
>>> 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 i=
n
>> 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 b=
e 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 t=
o
>> 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=E5=B9=B412=E6=9C=8816=E6=97=A5(=E6=B0=B4) 23:46 zeriyoshi <zeriyosh=
i@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 a=
n
>>> > object like other languages (e.g. Java).
>>> >
>>> > So, I created a PHP Extension and proposed it to PECL.
>>> >
>>> > https://marc.info/?l=3Dpecl-dev&m=3D160795415604102&w=3D2
>>> > 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 we=
b.
>>> >
>>> > Second suggestion is to stop using the Combined LCG as the default se=
ed
>>> > 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 b=
e
>>> > 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 <zeriyoshi@gmail.com>
>>> >
>>>
>>

--000000000000a42f4c05b8391897--