Re: [RFC] [Under Discussion] Random Extension 4.0
| From: | Tim Düsterhus | Date: | Wed, 16 Feb 2022 11:24:51 +0000 |
| Subject: | Re: [RFC] [Under Discussion] Random Extension 4.0 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117046@lists.php.net to get a copy of this message | ||
Hi
On 2/16/22 12:04, Go Kudo wrote:
Attachment: [application/x-php] test_rng.php
Attachment: [text/x-csrc] xoshiro128pp.c
Thanks for the good idea. I changed the NumberGenerator to Engine and changed generate() to return a string as suggested.Thanks, I've already seen the updated PR and played around with it. This feels much better now. As a test I implemented xoshiro128++ in pure userland (it being a 32 Bit RNG avoids the signedness issues in PHP userland) and compared it against the reference implementation in C. Find my implementations attached. Both versions give the same results (little endian encoding):
$ gcc xoshiro128pp.c ; ./a.out
fa3c872c
$ sapi/cli/php test_rng.php
string(8) "fa3c872c"
The main changes since last time are as follows: - The userland implementation can now specify the width of the random number sequence that can be generated - Random\Engine::nextByteSize() has been addedIs the nextByteSize() method actually required? PHP strings already know their own length.
- Random\Engine::generate() now returns a stringI've looked into your C implementation and it appears it still is affected by endianness issues. You can't simply memcpy the raw uintXX_t bytes into the char array. I believe the following should do the trick to for a consistent little endian encoding: bytes[0] = (generated >> 0) & 0xff; bytes[1] = (generated >> 8) & 0xff; bytes[2] = (generated >> 16) & 0xff; bytes[3] = (generated >> 24) & 0xff; The choice of endianness is arbitrary, but it needs to be consistent for every platform. Likewise when converting back to a number from bytes: number = (bytes[0] << 0) | (bytes[1] << 8) (bytes[2] << 16) | (bytes[3] << 24); I believe the same issue exists when initializing the XorShift with a string.
I have not yet come to a final conclusion on whether XorShift128Plus should be switched to another RNG. For example, what about implementing XorShift128Plus, but adding Xoshiro256** as well?That would be fine for me as well. But it might make it harder for the end user to choose an appropriate RNG. Best regards Tim Düsterhus
Attachment: [application/x-php] test_rng.php
Attachment: [text/x-csrc] xoshiro128pp.c