On Thu, Sep 9, 2021 at 6:31 AM Go Kudo <zeriyo...@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 = 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年9月7日(火) 17:28 Nikita Popov <nikita....@gmail.com>:
>
>> On Thu, Sep 2, 2021 at 5:10 PM Go Kudo <zeriyo...@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 for
>> mapping the raw random number stream into a range. However, the algorithm
>> we use for that is not exactly state of the art and requires two full-width
>> 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?) but it
>> would provide a different sequence than mt_rand(). Something we might want
>> to consider.
>>
>> Regards,
>> Nikita
>>
>
