Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117035
MIME-Version: 1.0
References: <CAMs36HcsGqNanQaro_VTkK_VKHNg-jqtshXpW-aCxdqpxHjMdw@mail.gmail.com>
 <41a1b458-4941-f34e-f1b4-e25b3298b80a@bastelstu.be> <CAMs36Hc4GCPUp2m+6N1LTP+hPrUv15iZF2QTCHBuAm+KDyXgfw@mail.gmail.com>
 <553ba7ca-3821-c2d9-f88f-b216013a887b@bastelstu.be> <a2683304-542f-e63a-e35f-04e5bb75f5d1@bastelstu.be>
 <CAMs36Hc+W_GkO4W+FB=ySFvc79DYy+M3TaT5qL0Ap9NwmY=6dQ@mail.gmail.com> <2c667812-88c8-0b7b-3558-561a1348d0b2@bastelstu.be>
In-Reply-To: <2c667812-88c8-0b7b-3558-561a1348d0b2@bastelstu.be>
Date: Tue, 15 Feb 2022 20:48:29 +0900
Message-ID: <CAMs36HctoKykr=aSVCr_DtFEpeF1fZke5LGCOFu_-oQEzL06Ug@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000003617ab05d80d1d67"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0
From: g-kudo@colopl.co.jp (Go Kudo)

--0000000000003617ab05d80d1d67
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B42=E6=9C=8815=E6=97=A5(=E7=81=AB) 19:03 Tim D=C3=BCsterhus <tim=
@bastelstu.be>:

> Hi
>
> On 2/15/22 04:58, Go Kudo wrote:
> >> Regarding "unintuitive": I disagree. I find it unintuitive that there
> are
> > some RNG sequences that I can't access when providing a seed.
> >
> > This is also the case for RNG implementations in many other languages.
> For
> > example, Java also uses long (64-bit) as the seed value of the argument
> for
> > Math.
> >
> >
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Ra=
ndom.html#%3Cinit%3E(long)
>
> java.util.Random is a LCG with only 48 Bits of state. A single 64-bit
> signed long is sufficient to represent the state.
>
> > On the other hand, some languages have access to the complete internal
> > state. Python, for example, accepts bytes or bytearrays.
> >
> > https://docs.python.org/3/library/random.html#random.seed
> >
> > However, making strings available in PHP may lead to incorrect usage.
> >
> > I think we can safely do this by making the seed argument accept both i=
nt
> > and string, and only using it as the internal state if string is
> specified
> > and it's 128-bits long.
>
> That's a solution that would work for me.
>
> >> 1. Would you expect those two 'var_dump' calls to result in the same
> > output?
> >
> > Added __debugInfo() magic method supports.
> >
> >
> https://github.com/php/php-src/pull/8094/commits/78efd2bd1e0ac5db48c272b3=
64a615a5611e8caa
>
> Don't forget to update the RFC accordingly. It would probably be helpful
> if you would put the full class stubs into the RFC. I find that easier
> to understand than a list of methods.
>
> >> generate() should return raw bytes instead of a number (as I suggested
> > before).
> >
> > I don't think this is a very good idea.
> >
> > The RNG is a random number generator and should probably not be
> generating
> > strings.
>
> I'd say that the 'number' part in RNG is not technically accurate. All
> RNGs are effectively generators for a random sequence of bits. The
> number part is just an interpretation of those random sequence of bits
> (e.g. 64 of them).
>
> > Of course, I am aware that strings represent binary sequences in PHP.
> > However, this is not user-friendly.
> >
> > The generation of a binary string is a barrier when trying to implement
> > some kind of operation using numeric computation.
>
> I believe the average user of the RNG API would use the Randomizer
> class, instead of the raw generators, thus they would not come in
> contact with the raw bytes coming from the generator.
>
> However by getting PHP integers out of the generator it is much harder
> for me to process the raw bits and bytes, if that's something I need for
> my use case.
>
> As an example if I want to implement the following in userland. Then
> with getting raw bytes:
> - For Randomizer::getBytes() I can just concatenate the raw bytes.
> - For a random uint16BE I can grab 2 bytes and call unpack('n', $bytes)
>
> If I get random 64 Bit integers then:
> - For Randomizer::getBytes() I need to use pack and I'm not even sure,
> whether I need to use 'q', 'Q', 'J', 'P' to receive an unbiased result.
> - For uint16BE I can use "& 0xFFFF", but would waste 48 Bits, unless I
> also perform bit shifting to access the other bytes. But then there's
> also the same signedness issue.
>
> Interpreting numbers as bytes and vice versa in C / C++ is very easy.
> However in PHP userland I believe the bytes -> numbers direction is
> easy-ish. The numbers -> bytes direction is full of edge cases.
>
> > If you want to deal with the problem of generated size, it would be mor=
e
> > appropriate to define a method such as getGenerateSize() in the
> interface.
> > Even in this case, generation widths greater than PHP_INT_SIZE cannot b=
e
> > supported, but generation widths greater than 64-bit are not very usefu=
l
> in
> > the first place.
> >
> >> The 'Randomizer' object should buffer unused bytes internally and only
> > call generate() if the internal buffer is drained.
> >
> > Likewise, I think this is not a good idea. Buffering reintroduces the
> > problem of complex state management, which has been made so easy. The
> user
> > will always have to worry about the buffering size of the Randomizer.
>
> Unfortunately you did not answer the primary question. The ones you
> answered were just follow-up conclusions from the answer I would give:
>
>       var_dump(\bin2hex($r1->getBytes(8)));
>       var_dump(\bin2hex($r2->getBytes(4)) . \bin2hex($r2->getBytes(4)));
>
> As a user: Would you expect those two 'var_dump' calls to result in the
> same output?
>
> >> Why xorshift instead of xoshiro / xoroshiro?
> >
> > The XorShift128Plus algorithm is still in use in major browsers and is
> dead
> > in a good way.
>
> I believe that that the underlying RNG in web browsers is considered an
> implementation detail, no?
>
> For PHP this would be part of the API surface and would need to be
> maintained indefinitely. Certainly it would make sense to use the latest
> and greatest RNG, instead of something that is outdated when its first
> shipped, no?
>
> > Also, in our local testing, SplitMix64 + XorShift128Plus performed well
> in
> > terms of performance and random number quality, so I don't think it is
> > necessary to choose a different algorithm.
> >
> > If this RFC passes, it will be easier to add algorithms in the future.
> If a
> > new algorithm is needed, it can be implemented immediately.
>
> Best regards
> Tim D=C3=BCsterhus
>

> java.util.Random is a LCG with only 48 Bits of state. A single 64-bit
signed long is sufficient to represent the state.

Sorry about that. Java was not affected by this problem.

At first, I updated the RFC to the latest status.

https://wiki.php.net/rfc/rng_extension

I need some time to think about the current issue. I understand its
usefulness, but I feel uncomfortable with the fact that the NumberGenerator
generates a string.

I also wonder about the point of changing RNG to XorShift128Plus. There are
a number of derived implementations, which RNG do you think is more
suitable?

Regards,
Go Kudo

--0000000000003617ab05d80d1d67--