Re: [RFC] RNG fixes
| From: | Fleshgrinder | Date: | Wed, 22 Jun 2016 17:46:59 +0000 |
| Subject: | Re: [RFC] RNG fixes | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-94212@lists.php.net to get a copy of this message | ||
On 6/21/2016 11:40 PM, Rowan Collins wrote:
> Hi,
>
> I already wrote this message once, but it seems to have evaporated into
> the ether. So apologies if it reappears and this is revealed as a poor
> duplicate of it!
>
> I think the push to remove "cruft" would make more sense if the
> replacements were less obviously "cruft" in their own right. If I have
> to polyfill pcg_rand() on old servers and mt_rand() on new ones, I'd be
> tempted to just implement wtfbbq_rand() and have done with it, because
> the names, and even the algorithms they represent, are pretty
> meaningless to me.
>
> As with libsodium, I think we should avoid replacing one set of
> overly-specific implementations with another, and saying "this time
> we've got it right". Instead, we should look at what people actually
> want the functions *for*, and hide the implementation as much as possible.
>
> For instance, for reproducible (seedable) random sequences, how about a
> function random_int_sequence($seed, $min, $max) which returns a
> generator, so you could write "$user_seq =
> random_int_sequence($user_seed, 0, 10); $user_pick = $user_seq();" Or
> maybe it could return a closure, or an object - either way, something to
> replace the global state of (mt_)srand.
>
> Perhaps a random_int_fast() function with big warnings that it's not to
> be trusted for crypto, but performs really well if all you're doing is
> picking which image banner to show on your home page.
>
> Use whatever RNG you want under the hood, make a declaration of whether
> or not it's stable cross-platform and cross-version, and give users an
> actual reason to change their code. Then consider other use cases: a
> better uniqid(), shuffling, maybe built-in UUID support...
>
> Then, IF the new APIs become popular, we can come back to talking about
> removing rand() and mt_rand(), because we'll have replaced them with
> something substantially better, not just another variant on the same thing.
>
> Regards,
>
Yes, yes, yes! :)
I would still like to deprecate rand() but probably leave it to Nikic
because people actually listen to him. ;)
@Tom Worster: I will not answer to any other message in this thread
today but I think we are essentially on the same page regarding PCG and
its suitability for PHP, it just needs time to mature. I think we also
agree regarding the MT situation.
However, I think that it makes sense to tackle the problem that people
use mt_rand() incorrectly and Rowan's proposal here matches the last
proposal I made: it's just even better and he is as always much better
in summing things up. :)
Maybe we could do some name brain storming?
1. random_int_sequence()
2. random_int_fast()
3. random_int_seedable()
4. random_pseudo_int()
5. pseudorandom_int()
6. random_deterministic_int()
7. deterministic_random_int()
8. ????
[1] Somehow unclear what sequence means here if you just want to
randomly pick an entry from an array.
[2] This might still suggest to people that they can use it for crypto,
just faster. I really like it but I don't think its perfect.
[3] Sounds nice to me.
[4] What is a pseudo int?
[5] Would create a new prefix and probably not show up in some code
completions together with the other random functions. :( Other than that
it would describe it best.
[6] Long but to the point.
[7] Again too long and it creates a shitty new prefix.
The signature is clear in my opinion and exactly as Rowan had it:
prng(int $seed, ?int $min = 0, ?int $max = PHP_INT_MAX): int;
--
Richard "Fleshgrinder" Fussenegger
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc