Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94242
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU5pmAoRJ15f=WE6+rDbEimhSVo3Ln3Vk27huWRLb_N00g@mail.gmail.com>
References: <CAPwsocFZQdU2bt0OETeJMQYBXVUkK8ygB5jTb4ML3df4GZWdVA@mail.gmail.com>
 <e28227a3-d5b1-b971-3362-c6d31768aa44@fleshgrinder.com> <cf009374-d159-886c-3a25-643ebb7f91e5@gmail.com>
 <f5807c28-6f0e-d7a7-b460-335cb0354d07@seld.be> <2f92fa26-5f50-0e68-c1fc-de79f17c201e@fleshgrinder.com>
 <8b48f847-bbba-03f8-4b2e-9cd0841b484e@gmail.com> <65ea0142-c2d6-f4ed-e98e-b7c7fbc51c58@fleshgrinder.com>
 <CAF+90c9N3Mk99OOhLi_NgM6GKYhh0a5gXk2nH1fmnyqz=f0Zbw@mail.gmail.com>
 <D3915644.6FA67%fsb@thefsb.org> <CAF+90c9sONJVu6BFafM8h9DKOK6eaj+xsk_Jt3kd-DTVBVn6Fg@mail.gmail.com>
 <a8471ece-05e2-ec5b-c3b2-2484b6da4675@gmail.com> <0e4655b3-d0cb-f1cc-6e39-c336ed51e2de@gmail.com>
 <CAEZPtU5pmAoRJ15f=WE6+rDbEimhSVo3Ln3Vk27huWRLb_N00g@mail.gmail.com>
Date: Fri, 24 Jun 2016 08:38:08 +0700
Message-ID: <CAEZPtU43HkxXc-irv2OCatBMShp1RyDCQN9UDpMNQ-w9n8M75Q@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] RNG fixes
From: pierre.php@gmail.com (Pierre Joye)

On Fri, Jun 24, 2016 at 8:35 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> hi,
>
> On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev
> <smalyshev@gmail.com> wrote:
>> Hi!
>>
>>> I would prefer something like random_fast_int() == mt_rand() == rand(),
>>> with clear documentation on when to use random_fast_int() instead of
>>> random_int(), and a note on the others that "since 7.2, mt_rand() is an
>>> alias for random_fast_int()" etc. (Not wedded to the name
>>> random_fast_int, we can bikeshed that later.)
>>
>> That sounds to me like a good way to proceed too. I don't think it's a
>> big deal it mt_rand won't be using specific MT algorithm anymore, I see
>> very small number of places where it would matter.
>>
>> One thing to consider is that there might be test scenarios, sequences,
>> etc. that depend on specific seed and will be broken by changing the
>> implementation (tests relying on specific rand are not the very best
>> idea, but they do happen), but I think this kind of thing may be
>> acceptable for a major version. Would like to hear thoughts on this though.
>
> fast_int or fast whatever looks bad to me. But we know that.
>
> Also, about mt_rand, it costs nothing to have a compat mode for the
> cases where the current (standard or not is not relevant)
> implementation is being relied on.
>
> More generally about the random APIs, there are many good non crypto
> safe RNGs, and there will be more. Each of them have their own use
> cases. I do not think that arbitrary choose, change, actualized them,
> in major versions or not, is a good thing.
>
> I would rather prefer to have a more flexible API allowing to choose
> one algorithm for a run. It is also good to have a default per
> category (strong, weak, fast for example) so one can use the current
> default for a given need.
>
> A good API for RNG is https://bitbucket.org/haypo/hachoir/wiki/Home.
> It allows flexibility while having default and the ability to choose a
> specific implementation if desired. My main point is to do not
> penalize valid uses because some code will never ever do the right
> thing (tm). A language cannot prevent bad behaviors but do not have to
> punish good cases by removing useful features for the "good of all".

Last but not least, mt_rand must remain using Mersenne Twister.
Options can define which implementation (at runtime, no ini please).
It will be very weird that MT uses some randomly chosen
implementation. New APIs can expose other "better" algorithms.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org