Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80390
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 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 00:23:34 +0000
Message-ID: <CAPwsocGwHvrZiA9ekhJ=1DkK_e+VeGqn1KdVqsnHjC9qHWPALw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: leight@gmail.com (Leigh)

On 11 January 2015 at 22:12, Andrea Faulds <ajf@ajf.me> wrote:
>   * 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 notice
>   * Use a 64-bit random number generation algorithm on 64-bit platforms (or invoke the 32-bit generator twice)
>

I have to object to removing the C stdlib rand(). mt_rand() is
significantly slower and when I don't care about the "quality" of the
random numbers the choice is obvious. Now if that means mt_rand() goes
to rand(), and rand() goes to something like fast_rand(), that is
fine, I don't care, I just don't think we should ditch the standard
rand function.

I do however think the default limits should be appropriate for the
underlying platform, so 64 bit values returned by default on 64 bit
platforms.

The MT internal state is large enough for you to consume 64 bits at a
time, no need to call it twice.