Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117899
Message-ID: <9c907fc8-ae1c-7c2f-c77a-727d03e70407@bastelstu.be>
Date: Fri, 10 Jun 2022 12:42:36 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Go Kudo <g-kudo@colopl.co.jp>, internals@lists.php.net
References: <CAMs36Hdq7Bh+fj62NBY7L5RSMy-4OOncs3fKzUQu9GzUf-zMWw@mail.gmail.com>
 <77a67ec1-2b32-0e86-3714-9b2600691c18@bastelstu.be>
 <CAMs36HdOvg0im4m=tzkO56LrUd22u-Ck0u39gBCpTBToqU4fRg@mail.gmail.com>
In-Reply-To: <CAMs36HdOvg0im4m=tzkO56LrUd22u-Ck0u39gBCpTBToqU4fRg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Vote] Pre-vote announcement for Random Extension
 5.x
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 6/10/22 12:02, Go Kudo wrote:
>> 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.

Thanks, that looks good to me.

> * 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....

Don't worry. I understand that using a foreign language can sometimes be 
hard - I am not a native speaker of English either and I suspect that 
this also applies to many other participants.

> 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.

If I understand you correctly, then (1) is what I am looking for: It 
should be spelled out explicitly what behavior the user may rely on and 
what should be considered an implementation detail.

Something like the following would work for me:

----

The engines implement a specific well-defined random number generator. 
For a given seed it is guaranteed that they return the same sequence as 
the reference implementation.

For the Randomizer it is considered a breaking change if the observable 
behavior of the methods changes. For a given seeded engine and identical 
method parameters the following must hold:

- The number of calls to the Engine's ->generate() method remains the same.
- The return value remains the same for a given result retrieved from 
->generate().

Any changes to the Randomizer that violate these guarantees require a 
separate RFC.

----

> 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.

Can you comment on whether the Randomizer behaves identically on both 32 
and 64 bit PHP and also on little endian and big endian architectures? 
As an example: Will ->getInt() calculate the same "uniform distribution" 
on all bitnesses? If not I consider that a bug.

The engines *should* behave identically, because of the "little endian 
string" return value.

If that's already the case then something like the following should be 
added to the RFC guarantees:

- The implementation will guarantee that the same results are returned 
independent of the processor architecture (little endian / big endian) 
and integer bit length's (32 / 64).

> 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.)
> 


Best regards
Tim Düsterhus