Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F4.07.51557.FF96F885@pb1.pair.com>
References: <CAGa2bXar3gUv7Ejwv2ngef3-4xu5+RYsCG26X7=0wPwf5kMaMQ@mail.gmail.com>
 <d1750949-d478-9720-277c-eb869444b2be@gmx.de> <F4.07.51557.FF96F885@pb1.pair.com>
Date: Tue, 31 Jan 2017 19:24:26 +0900
Message-ID: <CAGa2bXadF+zUQ=bFzTa6h8Aq67ensvJVrbAEjWzdj3BcuuRMGg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1147c8249bfdc205476158ff
Subject: Re: [PHP-DEV] Re: Reseeding rand()/mt_rand()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1147c8249bfdc205476158ff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Andrea,

On Tue, Jan 31, 2017 at 1:29 AM, Andrea Faulds <ajf@ajf.me> wrote:

>
> Christoph M. Becker wrote:
>
> Just a quick idea:
>>
>> <?php
>>
>> class PNRG {
>>     public function __construct($seed =3D null) {=E2=80=A6}
>>     public function get() {=E2=80=A6}
>> }
>>
>>
> I've long favoured an API along these lines. One size does not fit all,
> you need two APIs for (non-crytographic) random numbers:
> - automatically-seeded, non-reproducible numbers (a global function like
> rand())
> - manually-seeded, reproducible number sequences (objects)
>

I agree. We should have PRNG object.


>
> Currently we mix these two, and it's a mess. The easy solution would be a
> random number-generating object like you propose, to cover the second
> use-case. We could also introduce a non-manually-seedable global PRNG als=
o,
> if desired. Perhaps as a static method of that class.
>

Mixing system and user seeded PRNG is mess. I totally agree.
Let's divide them into separated states.


>
> One thought: it'd be nice if you had two different methods, one that
> mutates in places, and one that doesn't, i.e.:
>
> $prng1 =3D new PRNG(SEED);
> [$randomNumber, $prng2] =3D $prng2->getWithNewPRNG();
>
> v.s.:
>
> $prng =3D new PRNG(SEED);
> $randomNumber =3D $prng->get();
> $randomNumber2 =3D $prng->get();


My current objective is to make existing API to work, so resource may be
used
to set/get PRNG state.

*** Initialize and Create new PRNG state resource ***
resource mt_srand([int|string $seed])

resource: MT rand state resource.
$seed: I would like to allow large seed like Python and Ruby.
            When seed is string, use all bits for MT rand state
initialization.
            Example usage: mt_srand(random_bytes(2000));

*** Get random number from state resource ***
int mt_rand() // System state
int mt_rand(resource $state) // Specified user state
int mt_rand(int $min , int $max [,resource $state]) // Specified user state
if $state is passed



I suppose most codes do not use mt_srand()/srand(). With new API, users may
write
code like

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
// We need the same random numbers here
$my_state =3D mt_srand(1234);
// NOTE: mt_srand(), w/o seed, creates new PRNG state.
for ($i=3D0; $i < 10; $i++) {
   // Use my PRNG state
   $my_rand[] =3D mt_rand($my_state);
}

Somewhere later in code

// We need somewhat random numbers for non CS purpose
for ($i=3D0; $i < 10; $i++) {
   // System PRNG state is affected by mt_srand()/srand()
   // and $my_other_rand will have proper random values
   $my_other_rand[] =3D mt_rand();
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This requires code modifications, but it isn't too bad.
Problem is this change would be master only and
other functions, e.g. shuffle(), have optional state resource
parameter or not.

Thoughts? Comments?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1147c8249bfdc205476158ff--