Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80395
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <76B8D342-43E7-42E6-AD82-FCF7C5CA8658@ajf.me>
References: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me> <54B30DB9.3000003@seld.be>
 <76B8D342-43E7-42E6-AD82-FCF7C5CA8658@ajf.me>
Date: Mon, 12 Jan 2015 09:55:08 +0900
Message-ID: <CAGa2bXanYJhDfmCNjL9iaOe+aHh=W77zjeac6kB_Uyt1y2WNRA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Jordi Boggiano <j.boggiano@seld.be>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134050c974378050c69f790
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1134050c974378050c69f790
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Andrea,

On Mon, Jan 12, 2015 at 9:05 AM, Andrea Faulds <ajf@ajf.me> wrote:

> > On 11 Jan 2015, at 23:56, Jordi Boggiano <j.boggiano@seld.be> wrote:
> >
> > On 11/01/2015 22:12, Andrea Faulds wrote:
> >>   * Make mt_srand() and srand() do nothing and produce a deprecation
> notice
> >
> > That is the only point with which I disagree. Looking at
> http://3v4l.org/FLHBV we see that while indeed across PHP versions the
> result has not always been the same, it generally is, and especially with=
in
> one given version setting a seed means you get predictable results.
> >
> > This has benefits in some cases like fixtures generation where it might
> not be important if the output changes when you upgrade PHP, but you don'=
t
> want entirely different fixtures every single time. Obviously if we could
> guarantee the algo won't change it would be even better.
> >
> > Bottom line is I think it's important to have the ability to set the
> seed yourself.
>
> >
> > On 11 Jan 2015, at 23:57, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> >
> > However, I object removal of srand.
> > Game programmers need "the same random sequence" on occasion.
> > There should be srand to get the same sequence for repeatable behaviors=
.
> >
> > rand()/srand() may be renamed to sys_rand()/sys_srand() (or whatever
> > suitable name for them) in case user needs system random sequence
> > for whatever reasons. I don't insist to keep system's rand/srand, thoug=
h.
>
> I don=E2=80=99t disagree with having some mechanism for predictable rando=
m number
> generation from a seed, but I think the global random number generator is
> the wrong place to do it. It=E2=80=99s not guaranteed to be predictable, =
and
> everything uses it, so some library you=E2=80=99re using might advance it=
 without
> you realising.
>
> Much better would be to add a new, OOP API that gives you your own number
> generator (no global state) and requires explicitly specifying the
> algorithm (cross-version compatibility), with a guarantee that it won=E2=
=80=99t
> break in new PHP versions.
>
> Something like this, maybe:
>
>     $numgen =3D new RandomNumberGenerator(RAND_MERSENNE_TWISTER, time());=
 //
> could auto-seed with time()
>     $randInt1 =3D $numgen->getInt(0, 100); // gets random integer and
> advances this generator
>     list($randInt2, $numgen) =3D $numgen->newGetInt(0, 100); // gets rand=
om
> integer and returns a new, advanced generator
>     $serialised =3D $numgen->serialiseState(); // Or maybe
> $numgen->getSeed() ?
>
> Does that work?


It works, but I prefer to have procedural API also (and OO API if it is
needed.)
I like multi paradigm programming language.

Pseudo random number generator is pseudo. We are better off with real
random generator when cryptographic random number is needed. So
renaming mt_rand() -> rand() / rand() -> sys_rand() and keeping mt_rand()
alias would be enough. IMO.

BTW, difference between 32bit and 64bit platforms would not be a problem
as long as it is documented.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1134050c974378050c69f790--