Hi all,
There has been a bit of discussion about rand(). I really appreciate that,
though I would have preferred if it was held BEFORE the changes I (tried to)
make.
Okay, back to business.
By special request, as short as possible:
(I assume you've read the latest proposal, if not, go to
http://www.a-es2.uu.nl/~jeroen/rand/ )
[This part only applies to the controversary part of the proposal, AKA the
'redesign' (which it isn't anymore)]
###Pro's:
* Easier for the user
* All randomness controllable (wasn't the case before).
* The choice-for-algorithm should NOT be to the php-programmer if you're
after random numbers. (this is very important)
* Make it _possible_ to add a real-random-number generator which will be
used by PHP
* Namespace-cleaning: rand, srand, getrandmax, mt_rand, mt_srand,
mt_getrandmax and lcg_value not needed anymore, simply 'random',
'random_set', and possibly 'random_value' for getting a [0,1) float.
###Contra's:
* "Slower": not significantly, comparing just-before-jani's-revert and
just-after-jani's-revert, it turns out that the new way is 14 ns slower
(1387ns vs 1373ns). To compare: 1 + 1 takes 712 ns. All this on a quite old
300MHz machine. And the code wasn't optimized at all.
(recall that there go 1000000000 (10^9) nanoseconds in a second)
[I did 10x 10000000 (10 x 10^7) experiments, and applied some statistics,
and concluded that the measurement results are accurate to a few
nanoseconds]
* More complicated C-code: True of course, but is that really a reason?
* Leaks, bad coding style, etc: Code wasn't finished yet, of course, that
needs (and will be) fixed, but that's not the issue in this stage
* Don't fix if it isn't broken: This is not a fix. And it 'fixes' the
disadvantages of the current system mentioned in "pro's".
### Stop reading here, and comment on these pro's and contra's (especially
if I forgot one). Unless you're really interested, you could read further. A
bit more below, there are some sample scripts.
Other proposed changes are without any objections, and can also be
implemented quite straight-forwardly:
* Easy seeding by user
Sterling recently enhanced srand() to invent a seed by itself. There was
also no discussion about this point.
* Seeding on script startup
There are no objections, so that should be added soon. It is already done
iff you have crypt()
* Thread safe rand()
Can be done, and should be done IMHO. This is no big deal either. 3.3073802
==================================
Okay, now some examples from practice, why the one way is easier:
php.ini: random_generator = "mt"
<?php // this script uses MT all over:
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?>
<?php // this script uses lcg all over, and will produce same output each
time
// differs from previes script only by first line.
random_set(RAND_LCG, 123);
echo random();
$a = array('a','b','c');
var_dump(shuffle($a));
?>
# how to extend:
php.ini:
random_generator = "random.org"
<?php // uses true random numbers
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?>
php.ini: irrelevant
<?php // this script uses MT all over:
// force mt-generation. This is something that shouldn't happen in good
scripts. Which one is the best random-number-generator can only be decided
by system-admin (because could be system-dependent)
ini_set("random_number_generator", "mt");
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?>
===============
Currently, you cannot control all randomness, you cannot decide what
algorithm shuffle & co should use, you need to change all calls to rand() if
you decide to switch to other algorithm.
Currently there are 3 random number generators in the core of PHP, all are
different and have there specific properties. They should be easily easy to
use, which isn't the case now. lcg for example can't
currently be used well as integer-yielding function.
--Jeroen
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
