Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116238
MIME-Version: 1.0
References: <CABTDVhBRpD=nWBk2xGLEmdcWwOzCeqGeqH5vLSugPFOeEN9Mog@mail.gmail.com>
 <CAF+90c-j84_gXvnChewQoJbHnGLWgcHfszp=GgFF8_sAaPahdA@mail.gmail.com>
 <CABTDVhCuVCCpH5Agu6ozDEcuj8_z4=xB81VVtme+0CDXOxN10A@mail.gmail.com> <CAF+90c99Z=J7Qwbd_B+VeyaM5p9RfqzxwBvCVJiEZDtcKhAmGg@mail.gmail.com>
In-Reply-To: <CAF+90c99Z=J7Qwbd_B+VeyaM5p9RfqzxwBvCVJiEZDtcKhAmGg@mail.gmail.com>
Date: Thu, 7 Oct 2021 21:33:12 +0900
Message-ID: <CABTDVhAN77PS4d65EdLhVx0egvaGGK=POqjTiQMT8AO4dm8H6A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f9b6be05cdc277d9"
Subject: Re: [PHP-DEV] [RFC] Random Extension 3.0
From: zeriyoshi@gmail.com (Go Kudo)

--000000000000f9b6be05cdc277d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I had misunderstood this for a long time. Now I understand.
This is certainly something to think about.

However, I think we also need to consider compatibility. How about
something like the following?

```php
<?php

class MT19973_32
{
    public const SCALE_NORMAL =3D 0;
    public const SCALE_LEGACY =3D 1;
    public function __construct(?int $seed, int $flag =3D self::SCALE_NORMA=
L)
{}
}
```

2021=E5=B9=B410=E6=9C=884=E6=97=A5(=E6=9C=88) 19:24 Nikita Popov <nikita.pp=
v@gmail.com>:

> On Thu, Sep 9, 2021 at 6:31 AM Go Kudo <zeriyoshi@gmail.com> wrote:
>
>> Hi Nikita, sorry for the late reply.
>>
>> This is a difficult problem. For now, MT19937 is left for compatibility.
>> In other words, if you don't need compatibility, there is no benefit to
>> using it.
>>
>> What about implementing both a new MT and a compatible MT? A compatible
>> MT would have the following signature
>>
>> ```php
>>
>> use Random\NumberGenerator\Numbergenerator;
>>
>> /* for legacy compatibility */
>> class MT19937 implements NumberGenerator
>> {
>>     public function __construct(int $mode =3D MT_RAND_MT19937, int $seed=
) {}
>> }
>>
>> /* a new implementation */
>> class MersenneTwister implements NumberGenerator
>> {
>>     public function __construct(int $seed) {}
>> }
>> ```
>>
>> I had originally removed the MT_RAND_PHP implementation on the grounds
>> that legacy implementations should not be retained, but if the regular
>> Mersenne twister is to be retained for compatibility, I think it should =
be
>> as well.
>>
>> Also, maybe we should opt for a more SIMD friendly RNG.
>>
>
> To clarify, what I had in mind here is not the MT generator itself, but
> the scaling done in Random::getInt(). This scaling is independent of the
> used source. So while the raw numbers generated by
> Random\NumberGenerator\MT19937 would be the same as before, the result
> produced by Random::getInt() with this source wouldn't be.
>
> Regards,
> Nikita
>
>
>> 2021=E5=B9=B49=E6=9C=887=E6=97=A5(=E7=81=AB) 17:28 Nikita Popov <nikita.=
ppv@gmail.com>:
>>
>>> On Thu, Sep 2, 2021 at 5:10 PM Go Kudo <zeriyoshi@gmail.com> wrote:
>>>
>>>> Hi Internals.
>>>>
>>>> Expanded from the previous RFC and changed it to an RFC that organizes
>>>> the
>>>> whole PHP random number generator. Also, the target version has been
>>>> changed to 8.2.
>>>>
>>>> https://wiki.php.net/rfc/rng_extension
>>>> https://github.com/php/php-src/pull/7453
>>>>
>>>> Hopefully you will get some good responses.
>>>>
>>>
>>> This RFC currently tries to keep some semblance of compatibility with
>>> the existing mt_rand() algorithm by retaining the same implementation f=
or
>>> mapping the raw random number stream into a range. However, the algorit=
hm
>>> we use for that is not exactly state of the art and requires two full-w=
idth
>>> divisions at minimum. There are more efficient scaling algorithms based=
 on
>>> fixed-point multiplication, which are "nearly divisionless" (
>>> https://arxiv.org/pdf/1805.10941.pdf). The variant at
>>> https://github.com/apple/swift/pull/39143 is entirely divisionless.
>>>
>>> Doing this would improve performance (though I'm not sure by how much -=
-
>>> maybe once we add up our call overhead, it isn't important anymore?) bu=
t it
>>> would provide a different sequence than mt_rand(). Something we might w=
ant
>>> to consider.
>>>
>>> Regards,
>>> Nikita
>>>
>>

--000000000000f9b6be05cdc277d9--