2022年6月16日(木) 22:37 Tim Düsterhus <t...@bastelstu.be>: > 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 >
Hello Tim Thank you for your continued support. (1) Thanks! (2) You are indeed correct. I renamed it to pickArrayKey(). (3) This is a very tricky problem. As you point out, it took me a while to figure out PCG64 too. However, after statistical testing PCG64 (pcg_oneseq-128-xsl-rr-64) seems to do a good job. (Though Xoshiro256** does as well, and has a more obvious name.) Regarding the naming issue, I have looked at implementations in other languages (Python's NumPy and Rust) and none of them seem to be very clear. I agree with you about keeping the names clear. Although it is complicated, I don't think anyone would be particularly bothered by the name PcgOneseq128XslRr64. However, some people may continue to use MT because they don't understand it well. I think the possible options are as follows A. Rename PCG64 to PcgOneseq128XslRr64 B. Rename PCG64 to PcgOneseq128XslRr64 and then re-implement the more obvious Xoshiro256StarStar C. Remove PCG64 and re-implement Xoshiro256StarStart Personally, I think B is the best. What do you think? Regards Go Kudo
