Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80429
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me>
References: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me>
Date: Mon, 12 Jan 2015 18:07:57 -0800
Message-ID: <CAEZPtU4mz_yKXNVMZ=TpyLE9PhLKNG9qwDpvy65NUn2jPm5u5w@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Jan 11, 2015 at 2:12 PM, Andrea Faulds <ajf@ajf.me> wrote:
> Hey internals,
>
> As we=E2=80=99re moving to clean some things up in PHP 7, I think it migh=
t be worth looking at the rand()/mt_rand() situation.
>
> Currently, we have two standard-library functions to obtain a random numb=
er: rand() and mt_rand(). rand() uses the C standard library function, whic=
h on many stdlibs is slow or has a limited range (e.g. Win32 rand()=E2=80=
=99s maximum return value is SHORT_MAX). As a result, a drop-in replacement=
 was added, mt_rand(), which uses Mersenne Twister-based random number gene=
rator that=E2=80=99s probably better than what the C standard library provi=
des.
>
> Having two different random number functions is confusing to new users, a=
nd an oft-cited issue with PHP=E2=80=99s standard library. Intuitively, a u=
ser would expect rand() to be the function to get a random number, but actu=
ally they should be using mt_rand(), which is usually better.
>
> Another issue is the fact we allow random numbers to be seeded with srand=
() and mt_srand(). We have automatically seeded the random number generator=
 for a while now, so there is no need to do it manually. We also explicitly=
 do not guarantee that the random number generator will always produce the =
same output given the same seed, and in fact we=E2=80=99ve changed mt_rand(=
)'s behaviour in the past. This eliminates the primary use-case for manual =
seeding when there is automatic seeding: predictable output for procedural =
generation.
>
> Finally, a third issue is that mt_rand() does not produce good quality nu=
mbers on 64-bit platforms. mt_rand() will always produce a 32-bit value int=
ernally, and scale it up or down to fit the user-specified range. Unfortuna=
tely, this means that values for the $max parameter beyond 2^31 - 1 produce=
 numbers with poor granularity.
>
> Given all these, I would suggest that for PHP 7, we:
>
>   * Get rid of rand(), srand() and getrandmax()
>   * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), =
and getrandmax() but add mt_* aliases for backwards-compatibility
>   * Make mt_srand() and srand() do nothing and produce a deprecation noti=
ce
>   * Use a 64-bit random number generation algorithm on 64-bit platforms (=
or invoke the 32-bit generator twice)
>
> The end result should be that PHP has just one random number generation f=
unction, rand(), which can produce the full range from PHP_INT_MIN to PHP_I=
NT_MAX with no scaling. This would be far more intuitive, I think.
>
> Would that sound good?

I am all in favor of having new RNG functions to make it easier and
safer to use RNG with PHP.

However, I can only confirm what Rasmus said. Removing them is
absolutely not an option. There are dozen of valid usages of these
functions, from game engines to image processing via data simulation.
Dropping them or changing how they work will be a major pain for many
of these cases and a show stopper to upgrade to 7. Let not do that
please.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org