2022年2月16日(水) 20:24 Tim Düsterhus <t...@bastelstu.be>: > Hi > > On 2/16/22 12:04, Go Kudo wrote: > > 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 added > > Is the nextByteSize() method actually required? PHP strings already know > their own length. > > > - Random\Engine::generate() now returns a string > > I'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
Thanks Tim I forgot about the endian problem. Will try to fix it. Thank you very much. > Is the nextByteSize() method actually required? PHP strings already know their own length. This is a convenience of the current implementation. The native implementation does not use strings for performance reasons. This is because there is no way to know the valid width information they generate. I'm trying to think of some good ideas. > That would be fine for me as well. OK, I'm going to add Xoshiro128++ and Xoshiro256**. In order to make PHP easier to maintain, I think it is best not to add more implementations at random, so I will not add any more.
