Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112846
MIME-Version: 1.0
References: <CABTDVhCtBn7T0YyB+55Mxxz1UCYi7ov_Se2nX-Uxh3EmK4XkdA@mail.gmail.com>
In-Reply-To: <CABTDVhCtBn7T0YyB+55Mxxz1UCYi7ov_Se2nX-Uxh3EmK4XkdA@mail.gmail.com>
Date: Tue, 12 Jan 2021 09:40:36 +0900
Message-ID: <CABTDVhAFORgZgHYn=mJmEaa59ebbYte09uzzz41RG0pwOWeECQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000003203605b8a94637"
Subject: Re: [RFC] Object-scope RNG implementation
From: zeriyoshi@gmail.com (Go Kudo)

--00000000000003203605b8a94637
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have made some fixes to the implementation based on review. The current
implementation can be found at the following address (Thanks Tyson:
https://github.com/zeriyoshi/php-src/commit/5ff8882a8fbfaf4ffd5cc42fb5853c4=
a1a00c182
)

https://github.com/php/php-src/compare/master...zeriyoshi:object_scope_rng_=
type2

The points that seem to need discussion at the moment are as follows:

- Do we need this feature?
First of all this is more important than anything else.
I think it is necessary from a testing perspective and because it is going
to be difficult to consider global state in the future and some functions
are using RNGs at times that the user is not aware of.

- Do we need support for userland implementations?
I think this is necessary. Fixing the output of an RNG to an arbitrary
result is useful for testing special patterns.

However, this is currently problematic. At the moment, there is a complete
distinction between C implementations and userland implementations. This is
done based on whether the class is user-defined or not.

The classes provided by the C implementation are always final and cannot be
extended by the user.

I would like to make it extensible if possible, but currently I don't know
how to make it compatible with speed.

- How do you deal with the mixed 64/32 bit issue?
Some PRNGs, including XorShift128+, keep their internal state in uint64.
The XorShift128+ implementation supports serialization, which preserves the
internal state in a 32bit environment by converting numbers to strings.

However, __construct() still accepts seed values in int. This means that
certain states cannot be reproduced in a 32bit environment.

I think the support for 32bit environment will be reduced, and the
serialization support was done to help with the migration. Should
__construct() still accept a seed value in a string, so that all states are
available in a 32bit environment?

- What should we do with next64()?
The next64() method of the C implementation of RNG always throws a
ValueError in 32bit environments for now.

However, in a user implementation, everything is left up to the
implementation.

Personally, I think it would be better to define another interface for the
next64() method that inherits from RNGInterface, what do you think?

Regards,
Go Kudo

2021=E5=B9=B41=E6=9C=889=E6=97=A5(=E5=9C=9F) 19:00 Go Kudo <zeriyoshi@gmail=
.com>:

> Hi internals.
>
> I think I'm ready to discuss this RFC.
> https://wiki.php.net/rfc/object_scope_prng
>
> Previous internals thread: https://externals.io/message/112525
>
> Now is the time to let me know what you think.
>
> Regards,
> Go Kudo
>

--00000000000003203605b8a94637--