Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117966
Message-ID: <1717d744-b7df-b39d-f280-83283c11ec7b@bastelstu.be>
Date: Thu, 16 Jun 2022 15:37:44 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Go Kudo <g-kudo@colopl.co.jp>, internals@lists.php.net
References: <CAMs36Het5f=ojSw8H4kooZxub-COvhKmiJfYUUM7ioBSpVKFVA@mail.gmail.com>
 <CAMs36He3Cu+bh=9ycvpBPn+oCXCOuDT5ftkg9mV=qb8JeuPxAQ@mail.gmail.com>
 <dcb15100-d946-bcb6-f9cc-f13ea038a6ea@bastelstu.be>
In-Reply-To: <dcb15100-d946-bcb6-f9cc-f13ea038a6ea@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Random Extension 5.x
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 6/16/22 14:52, Tim Düsterhus wrote:
> (3) Naming of PCG64:
> 
> I must admit that the fact that PCG is a full family of similar, but not
> identical generators is one thing that made me (and still makes me)
> prefer the xoshiro family which has clearer names for its variants.
> 
> It was also pretty hard to find the PCG definitions on the PCG website,
> but I believe that it refers to this:
> 
> https://www.pcg-random.org/using-pcg-c.html#low-level-api?
> 
> In that case PCG64S would be consistent with the upstream high level API
> name. I am not sure if Pcg64s would be more readable, though.
> 
> It would definitely need a good explanation in the documentation which
> exact variant it is, though.

I've now had a look at the Paper [1], because I wanted to find out what 
the various bits and pieces within the full oneseq-128-xsl-rr-64 name 
mean and in the paper I came across section "6.3 Specific 
Implementations" which notes:

> The library provides named generators based on
> their properties, not their underlying implementations (e.g., pcg32_unique for a
> general-purpose 32-bit generator with a unique stream). That way, when future family
> members that perform even better are discovered and added (hopefully due to the
> discoveries of others), users can switch seamlessly over to them.

This implies that the official Pcg64s name might refer to a different 
implementation in the future. This makes it hard for PHP to keep the 
compatibility guarantee that a specific engine will always refer to a 
specific well-defined RNG. This implies that the engine needs to be 
named "PcgOneseq128XslRr64" to accurately describe the implementation. 
This - of course - is absolutely unwieldy. Note sure what the best 
course of action is here.

[1] https://www.pcg-random.org/pdf/hmc-cs-2014-0905.pdf

Best regards
Tim Düsterhus