Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <97CC6432-564B-4E28-B2DE-9C496FF1984D@zend.com>
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>
	<56C63A8A.3030809@gmail.com>
	<97CC6432-564B-4E28-B2DE-9C496FF1984D@zend.com>
Date: Fri, 19 Feb 2016 01:18:34 +0100
Message-ID: <CAF+90c9vAC3DceGNgio57UFgABNwc8B2s+qxiPuOVQ2oMpuuxQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11408dae808112052c146ce4
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11408dae808112052c146ce4
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 18, 2016 at 11:45 PM, Zeev Suraski <zeev@zend.com> wrote:

> > With rand functions, I don't think we need to touch them. For some
> > applications, low-key randomness is just fine - if you need to shuffle
> > array of 20 elements or randomize unit test to ensure you're not testing
> > same value all the time, low-quality randomness is completely fine. For
> > other applications, there are superior solutions and everybody who needs
> > them already uses them, but again I see no value in removing those
> > functions. It would only cause more breakage and make adoption of new
> > versions (already horrible) even slower.
>
> I think the obvious option here is to make rand() and srand() aliases to
> rand_mt() and srand_mt(), unless I'm missing something very basic, unless
> I'm missing something very basic here..?  I see zero reason to deprecate
> them and break so much code when we can simply 'upgrade' them at zero cost
> to both us and users.
>

The usual argument against aliasing rand() to mt_rand() is that it will
change the sequence that is generated for a specific srand() seed, thus
breaking code that relies on specific sequences. However, as removing the
functions in the future would break the code anyway, I think I agree with
you that just aliasing them is a better option.

We may need to discuss our non-cryptographic PRNG functionality anyway,
there's quite a number of issues:

 * rand(), the first function anyone will try, uses a potentially horrible
libc RNG
 * It was recently noticed that the mt_rand() implementation contains a
typo and our output differs from the original well-researched algorithm. As
yet it is unclear what that typo does to the quality of the output.
 * mt_getrandmax() is 2^31-1 even on 64-bit machines and numbers are scaled
using floating point multiplication. That means if you tell mt_rand() to
generate a 64-bit random numbers by specifying the range, only a tiny
fraction of numbers can actually be hit. I also strongly suspect that the
floating point scaling is inherently non-uniform even for smaller ranges.
 * Functions like array_rand() or shuffle() use rand() and not mt_rand(),
so if you're on Windows and your array is larger than some 30k elements the
output will likely be severely biased.
 * The array_rand() implementation is O(N) even if you only choose a single
key (likely by far the most common case). If you use array_rand() on a 1M
element array, we'll generate 0.5M random numbers on average.

Even though changing our PRNG implementations will break seed sequences, I
think the time has come to clean up this mess for 7.1. (We might also want
to consider to alias rand and mt_rand to an entirely new algorithm, not
MT19937. Nowadays PRNGs are available that have both better statistical
properties and are faster than MT.)

On a different note, I don't think that philosophical discussions on the
topic of how much we ought to be deprecating will be very productive --
this is one of those topics people tend to be very stubborn about ;) Some
people value stability above everything else, and for others the number one
evil in PHP is our reluctance to get rid of old ---crap--- cruft. It would
be nice if we could let voting decide that question, and keep this thread
focused on specific issues and suggestion. I.e. on one hand suggestions for
things that we may want to deprecate, together with reasoning for why we
should do it. And on the other hand alternatives to deprecation (your
suggestion for rand), reasons why something shouldn't be deprecated (e.g.
functionality not otherwise available, see hebrev; or migration would be
problematic because XYZ; or project ABC uses this heavily because ...)

Thanks,
Nikita

--001a11408dae808112052c146ce4--