Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112765
MIME-Version: 1.0
References: <CABTDVhA-FvEXdS+A=T5bJnX5YxjseN+ko14GUOqnuA52-omiiw@mail.gmail.com>
 <CABTDVhAYjCiZKGPJw6nMVHYp6wmVeqFzE+bK2Q3WzXW=9EV7ew@mail.gmail.com>
In-Reply-To: <CABTDVhAYjCiZKGPJw6nMVHYp6wmVeqFzE+bK2Q3WzXW=9EV7ew@mail.gmail.com>
Date: Tue, 5 Jan 2021 15:53:20 +0100
Message-ID: <CAF+90c9j5yYtHvjHZjF5jyGA=zqiyPxcGuWh2EEo=LuwK3CzgQ@mail.gmail.com>
To: zeriyoshi <zeriyoshi@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001514f805b8285fff"
Subject: Re: [PHP-DEV] Re: Improving PRNG implementation.
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000001514f805b8285fff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 fixe=
d
> 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 deprecatin=
g
> existing state-dependent RNG functions.
>
> I am seeking feedback on this proposal in order to take the RFC to the ne=
xt
> 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@g=
mail.com>:
>
> > Nice to meet you, internals.
> >
> > PHP 8.0 has been released. With the inclusion of JIT, PHP is about to b=
e
> > 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 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 <zeriyoshi@gmail.com>
> >
>

--0000000000001514f805b8285fff--