Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114782
MIME-Version: 1.0
References: <CABTDVhC_h-+pG54KuJu6g-CFQPqaMJ=PUF02FMjjENvP1dpfzg@mail.gmail.com>
In-Reply-To: <CABTDVhC_h-+pG54KuJu6g-CFQPqaMJ=PUF02FMjjENvP1dpfzg@mail.gmail.com>
Date: Tue, 8 Jun 2021 21:32:54 +0900
Message-ID: <CABTDVhDVE4JnAtLKCr8y+s_48LgNz_MM2G2OWscTkWLaL+wFTA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000f226505c4405c9b"
Subject: Re: [RFC] Under Discussion: Add Random class and RandomNumberGenerator
 interface
From: zeriyoshi@gmail.com (Go Kudo)

--0000000000000f226505c4405c9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello iinternals.

There doesn't seem to be much mention of it.
But, that may be because it has been discussed well in advance.
Thank you for participating in the discussion.

Now, if there is no particular discussion on this, I will try to start the
voting phase next week.
Of course, I will contact you separately.

However, I was looking back at the implementation and found only one point
of concern.

With the current implementation, the results of the following example will
match.

```php
$one =3D new Random();
$one->nextInt();
$two =3D clone $one;

var_dump($one->nextInt() =3D=3D=3D $two->nextInt()); // true
```

But, this is not true for user implementations.

```php
class UserRNG implements RandomNumberGenerator
{
    protected int $current =3D 0;

    public function generate(): int
    {
        return ++$this->current;
    }
}

$rng =3D new UserRNG();
$one =3D new Random($rng);
$one->nextInt();
$two =3D clone $one;

var_dump($one->nextInt() =3D=3D=3D $two->nextInt()); // false
```

This is because `$rng` is kept as a normal property and is managed by the
standard PHP mechanism. In other words, it is passed by reference.

This is not consistent with the built-in RNG behavior. However, I don't see
a problem with this behavior.
I feel that the standard PHP behavior is preferable to changing the
userland behavior in a specific way.

I would like to solicit opinions.

Regards,
Go Kudo

2021=E5=B9=B46=E6=9C=881=E6=97=A5(=E7=81=AB) 23:28 Go Kudo <zeriyoshi@gmail=
.com>:

> Hello internals.
> Thanks for continuing to participate in the discussion.
>
> I've sorted out the proposal, and finished writing and implementing the
> RFC.
> (Funny, I know.) I think it's time to start a discussion.
>
> https://wiki.php.net/rfc/rng_extension
> https://github.com/php/php-src/pull/7079
>
> The main changes since last time are as follows:
>
> - The ugly RANDOM_USER has been removed.
> - RandomNumberGenerator interface has been added for user-defined RNGs.
> - Random class is now final.
> - Random class now accepts a RandomNumberGenerator interface other than
> string as the first argument to the constructor.
> - INI directive has been removed. In 32-bit environments, the result is
> always truncated.
>
> What I'm struggling with now is the behavior when calling nextInt() in a
> 32-bit environment using a 64-bit RNG. It currently returns a truncated
> result, which means that the code loses compatibility with the result of
> running on a 64-bit machine.
> I was also considering throwing an exception, but which would be
> preferable?
>
> I would like to answer a few unanswered questions.
>
> > What is bias?
>
> I' ve confirmed that the bias issue in mt_rand has already been fixed and
> is no longer a problem.
>
> This implementation copies most of it from mt_rand. Therefore, this
> problem does not exist.
>
> Therefore, an equivalent method to mt_getrandmax() is no longer provided.
>
> > uint64 & right-shift
>
> This is a specification of the RNG implementation. PHP does not have
> unsigned integers, but RNG handles unsigned integers (to be precise, even
> the sign bit is random).
>
> As mentioned above, PHP does not have unsigned integers, which means that
> using the results generated by RNGs may cause compatibility problems in t=
he
> future. To avoid this, a 1-bit right shift is always required (similar to
> mt_rand()).
>
>
>
>

--0000000000000f226505c4405c9b--