Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112768
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>
In-Reply-To: <CAF+90c9j5yYtHvjHZjF5jyGA=zqiyPxcGuWh2EEo=LuwK3CzgQ@mail.gmail.com>
Date: Wed, 6 Jan 2021 02:39:54 +0900
Message-ID: <CABTDVhDAKu19iLmYx5n9st2b_vWNjBPcPtt+hwoxeg4r0xY3Gg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000074bb0b05b82ab27c"
Subject: Re: [PHP-DEV] Re: Improving PRNG implementation.
From: zeriyoshi@gmail.com (Go Kudo)

--00000000000074bb0b05b82ab27c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

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.

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?

Regards,
Go Kudo


2021=E5=B9=B41=E6=9C=885=E6=97=A5(=E7=81=AB) 23:53 Nikita Popov <nikita.ppv=
@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 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 fix=
ed
>> 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 deprecati=
ng
>> 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=E5=B9=B412=E6=9C=8816=E6=97=A5(=E6=B0=B4) 23:46 zeriyoshi <zeriyoshi=
@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=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 web=
.
>> >
>> > Second suggestion is to stop using the Combined LCG as the default see=
d
>> > value for each function.
>> >
>> > PHP's Combined LCG only uses PID (or ZTS Thread ID) and time as entrop=
y.
>> > 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 <zeriyoshi@gmail.com>
>> >
>>
>

--00000000000074bb0b05b82ab27c--