Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95140
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain gmail.com does not designate 188.117.41.47 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Sun, 14 Aug 2016 17:37:11 +0300
To: Tom Worster <fsb@thefsb.org>
Cc: internals@lists.php.net
In-Reply-To: <D3D5E13A.71009%fsb@thefsb.org>
References: <3d8be1faf8d4d3e5add3768d7a8eb16c@k-piste.dy.fi>
 <08ad472d-45d6-f8a8-0774-2b5c93aabfb7@thefsb.org>
 <d22ac6ef50381a201a1b53a3e6656339@k-piste.dy.fi>
 <64f21dfc-a2f7-e94d-cafd-e64d327391e2@thefsb.org>
 <6db7abd682383888c3bcedcfd8db7932@k-piste.dy.fi>
 <D3D5E13A.71009%fsb@thefsb.org>
Message-ID: <06236e4821c5634b30d531866230e4da@k-piste.dy.fi>
User-Agent: Roundcube Webmail/1.2.1
Subject: Re: mt_srand with array seed?
From: lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=)

On 2016-08-14 17:04, Tom Worster wrote:
> On 8/14/16, 5:45 AM, "Lauri Kenttä" <lauri.kentta@gmail.com> wrote:
> 
>> On 2016-08-13 18:53, Tom Worster wrote:
>>> On 8/12/16 2:48 PM, Lauri Kenttä wrote:
>>>> On 2016-08-12 21:40, Tom Worster wrote:
>>>>> mt_srand() will work. But what would be in the array? Integers from
>>>>> which the upper 32 bits, if they exist, are discarded?
>>>> 
>>>> mt19937ar.c contains init_by_array.
>>>> Compability with that would probably be a good goal,
>>>> unless someone can point out another widely used implementation.
>>> 
>>> Would mt_srand([1,2,3,4,5,6,7,8]) set the same seed on 32 and 64 bit
>>> machines?
>> 
>> Of course it would.
>> Or let's phrase it this way: can you think of any reason why it
>> shouldn't?
> 
> An array of N PHP (signed) integers in a 64bit PHP runtime can provide 
> 2N
> unsigned long seed values to MT. If mt_srand() did that then I don't 
> see
> how portability is maintained.

It would take some extra effort to use the 2N values.
It would really gain nothing, and it would cause confusion.

> Otoh, if, for the sake of portability, which I imagine most would 
> prefer,
> mt_srand() discards bits from 64bit input integers then mt_rand() will
> produce the same sequence for many different mt_srand() seeds. This 
> would
> be new and at odds with conventions of how seeds affect PRNG outputs.

If we allow an arbitrary seed length, there will always be multiple 
seeds which produce the same output, since any PRNG will have only a 
limited amount of internal state (in this case, 624 * 32 bits).

Note that mt_srand already discards the upper bits of the seed:

function f($seed, $n = 1000) {
   mt_srand($seed);
   $t = [];
   for ($i = 0; $i < $n; ++$i) $t[] = mt_rand();
   return $t;
}
var_dump( (1) ==  (1 + (1 << 32))); // false on 64-bit machines
var_dump(f(1) == f(1 + (1 << 32))); // true, since (1 << 32) is 
discarded

Now that I think about it, a method to save and restore the raw MT state 
would also be kind of nice. Although if this kind of things are 
seriously used, creating a MT19937 class would probably be cleaner than 
messing with the global PRNG.

It would be nice to hear about some real use cases for bigger seeds 
and/or setting the raw state.

-- 
Lauri Kenttä