Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117898
MIME-Version: 1.0
References: <CAMs36Hdq7Bh+fj62NBY7L5RSMy-4OOncs3fKzUQu9GzUf-zMWw@mail.gmail.com>
 <77a67ec1-2b32-0e86-3714-9b2600691c18@bastelstu.be>
In-Reply-To: <77a67ec1-2b32-0e86-3714-9b2600691c18@bastelstu.be>
Date: Fri, 10 Jun 2022 19:02:17 +0900
Message-ID: <CAMs36HdOvg0im4m=tzkO56LrUd22u-Ck0u39gBCpTBToqU4fRg@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000002f86c105e11509f9"
Subject: Re: [PHP-DEV] [RFC] [Vote] Pre-vote announcement for Random Extension 5.x
From: g-kudo@colopl.co.jp (Go Kudo)

--0000000000002f86c105e11509f9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B46=E6=9C=888=E6=97=A5(=E6=B0=B4) 0:24 Tim D=C3=BCsterhus <tim@b=
astelstu.be>:

> Hi
>
> On 5/31/22 11:54, Go Kudo wrote:
> > - More detailed description in RFC
> >
>
> a)
>
> For the Random\Engine interface I suggest to clarify that the returned
> bytestring will be interpreted as a little endian integer.
>
> b)
>
> I'm still missing an explanation of the guarantees the Randomizer
> implementation will make (last bullet point in
> https://externals.io/message/117295#117299).
>
> To me the guarantees is the most important thing about this RFC. As a
> user of the API I need to know what of the behavior can and what cannot
> change in future PHP versions. I don't really care whether the RNG is
> PCG64 or some Xoshiro. Both are great.
>
> The Engine part is pretty solid: They implement a well-defined RNG and
> any numbers are returned as little endian integers (see (a)). Either the
> implementation is correct or it is not. This is not likely to change in
> the future.
>
> However the Randomizer part is pretty undefined: As an example:
> ->getInt() will return an integer uniformly selected from the given
> range. But there's more than one way to perform this uniform selection.
> Will the algorithm stay the safe in future PHP versions? There are more
> examples in my previous emails.
>
> Best regards
> Tim D=C3=BCsterhus
>

Hi Tim.

Thanks for the continued feedback!

I have added the following regarding the points you pointed out.

* interface Random\Engine

> It has a single generate(): string method that generates random numbers
as a binary string. This string must be non-empty and attempting to return
an empty will result in a RuntimeException.
> If you implement a random number generator in PHP, the generated numbers
must be converted to binary using the pack() function, and the values must
be little-endian.

* class Random Randomizer

> The same current PHP algorithm is used to generate random numbers within
the specified range in Randomizer::getInt(). This is necessary for backward
compatibility.
> It also provides a guarantee of consistency in the future.

However, I understand that perhaps this fix will not satisfy your request.
I just do not have a good understanding of your intentions due to my poor
English....

I am considering the following possibilities regarding your intentions:

1. Should be stated in detail so that consistency of results is maintained
in the future.
2. Current PHP ranged random number generation algorithm has room for
improvement and should be examined further
3. Consistency of results is difficult to maintain in the future (Maybe
incorrect)

In case 1, I think the following statement would satisfy the requirement.

> The values generated by the seedable Engine guarantee future
reproducibility of results, and the Randomizer uses the results to process
them, so if the results generated by the Engine are identical, the
Randomizer's results will also be consistent.

Although the consistency of the Randomizer results is not mentioned here,
it would be a clear BC Break if the results were to change after the
Randomizer is officially implemented, so I do think it is sufficient that
an RFC be created and voted on as necessary.

In case 2, I also thought about it along the way. Nikita also taught me
about better algorithms: https://externals.io/message/115918#115982

But, I also think that the current PHP implementation is good enough, and
there is no need to change it to the point of breaking compatibility.

I think the current global scope MT implementation is very troublesome for
some use cases and should first be able to be drop-in-replaceable with this
implementation.

In case 3, I think it is necessary to guarantee consistency at least once
at the language level, even though this may change in the future. I have
already indicated the need for this in the RFC.

Most of all, I do not believe you intend this to be the case. (And this
sentence is not intended to offend you either. Please don't misunderstand
me.)

I would like to hear more about your opinion.
Regards,
Go Kudo

--0000000000002f86c105e11509f9--