[PHP-DEV] rand() broken on dev version?
php version:php4-STABLE-200212101230
apache: 2.0.43
os/platform:solaris 9/sparc
compiler: gcc 3.2
I ran configure with
./configure \
--prefix=${ROOT} \
--with-apxs2=/${ROOT}/bin/apxs \
--with-config-file-path=${ROOT}/conf \
--with-openssl=/usr/local \
--with-xml \
--enable-wddx \
--enable-track-vars \
--enable-trans-sid \
--enable-inline-optimization \
--disable-posix-threads \
--with-mysql=${MYSQLROOT} \
--with-pdflib \
--with-jpeg-dir \
--with-tiff-dir \
--enable-libgcc
The following code spits out 5, 36 times:
for ($i = 0; $i 36; $i++) {
$xrand = rand(5, 15);
echo $xrand br;
}
If I take out the args to rand() then it spits out random numbers
between 0 and whatever (presumably what getrandmax() returns).
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Rand - continue or not?
By special request: These are the pro's and contra's to the current proposal currently known with me. (see: http://www.A-Eskwadraat.nl/~jeroen/rand/ ) ###Pro's: * Hide seeding and such from the php-programmer * All randomness controllable, with clear syntax. * The choice-for-algorithm should NOT be to the php-programmer if you're after random numbers. * 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: [My code was less than 1% slower, so it's neglectable] * More complicated C-code [True] * Leaks, bad coding style, etc: [Implementation isn't discussed here] * Don't fix if it isn't broken [This is no fix, it's better syntax] Based on these arguments, I don't see any reason why not to go on. If anyone does see a reason, and/or I missed an argument, please mail it to php-dev and/or myself. TIA, Jeroen PS: The proposal is slightly updated because of a suggestion by someone (Joey IIRC) -- 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]
Re: [PHP-DEV] Rand...
Jeroen: It would probably help the discussion a lot if you would sort through all of the comments on your page, decide which are valid and which are not, and then rewrite the proposal. I can't seem to follow which comments are being accepted and which are being discarded. -- 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]
[PHP-DEV] Rand...
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 10 (10^9) nanoseconds in a second)
[I did 10x 1000 (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]
[PHP-DEV] Rand again
Hm, I notice there has been a huge discussion on php-dev, I think I'm going to read it first... My two previous mails were sent without having read the whole discussion. As I was tought, you shouldn't 'conclude' a discussion before everyone is heard, and I wasn't able to read and/or reply to newsgroup-messages (just mail... that explains occasional replies). --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]
Re: [PHP-DEV] Rand
PS: Egon, go read my reply when you asked that the first time. Wasn't I clear? It was in plain English though... I have only asked you, why have you deleted the comments. It was in my mail: - I DID NOT REMOVE THEM Ich habe den nicht weggeholt!!! I just MOVED them. That was already in my first reply. See rand_mt.c. --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]
Re: [PHP-DEV] Rand
On Mon, 3 Sep 2001 [EMAIL PROTECTED] wrote: I am really furious now, and this is why: * People here seem to read things here VERY selectively. On August 4th I submitted a first proposal, and Rasmus (and ONLY Rasmus) had some problems with it, being that this would break BC if ppl rely on the reproducibilty of rand() sequences. THAT WAS THE ONLY COMMENT I GOT. As I stated earlier, in most projects I have seen, discussions form around patches, very rarely do discussions form around abstract ideas (well productive discussions anyway). * On August 22th, I announced to branch ext/standard to start implementing the changes. IF SOMEONE HAD PROBLEMS WITH THE CHANGES AN-SICH, HE SHOULD HAVE SAID IT AT THAT MOMENT. You couldn't have missed the announcment, since there was a small discussion with Zeev about the branching. Yes, you branched it, but my impression, and the impression of other people was that you never had a finished body of code for us to test (and it seems you still didn't, as the code you committed to the main branch broke the compile). * On August 26th, (subject rand() redesign - please read) I announced that the code was alread looking like something, i.e. the general idea was already clear. I also referred AGAIN to my second proposal. Again, nobody had problems with it. No, we may just have not responded to your message or read it, as you said, you have a life outside of PHP; so do I. There are times when I can focus my attention on PHP (like the last couple of days I've had a pretty nasty cold, so its given me time to get work done), and then there are times when I can't, when work/friends/life get in the way. * On September 3rd, I merged it into MAIN. And now, suddenly everybody has problems with both semantics and implementation. I'm stunned. And angry. As Rasmus said, when you commit something to the main branch people take notice, if you commit something to a branch (unless of course its a release branch), people make it a secondary priority. I still haven't taken a look at the Zend Engine 2 branch and the new object model, except to merge some changes into it. That's a much more major set of changes than the rand redesign as well. When I get the time, I'll take a look, and believe me, if Andi has done something stupid (no offense Andi :), I'll speak up then, even if the code he committed is 5 months old at the time... All the time from August 22th until September 3rd, you also could have seen CVS-commit messages on PHP-CVS. If people are TOO LAZY to read ANY of these mails, they LOOSE IMO the right to comment to the code as it is today on a way that is done now. I have NO PROBLEM at all when ppl say something like On line 123 of rand.c, you do something like this-and-this, wouldn't that-and-that be more efficient/better/elegant/whatever. But I DO HAVE PROBLEMS with the reaction I got so far. We do have the right to comment on your code, whenever we feel like. If you write incorrect code (which didn't even compile btw), don't expect me to stay quite, cause I didn't make the comments when you would've liked them made. If in two months from now, I saw this commit, and saw what you did, I would still reccomend reverting it -- not because I don't like you, or respect the time that you put into it, but rather because from a technical standpoint its incorrect. The problem with what you committed is not as simple as line 123 has something wrong. Lines 1 - sizeof(commit) have something wrong. That's why I'm not suggesting you just change line 123, but rather revert the commit. The design is incorrect and the code is imho poorly written. How is it in PHP's interest to have code in the repository that's poorly written? Does it really matter when we comment on the code? The fact remains -- your code is incorrect. Whether we comment on it now, or in two years from now, has no bearing on whether or not it should be in the code repository (not taking into account the BC portion of the equation). People work hard and get patches rejected all the time, heck with APR (Apache Portable Runtime), even patches that are correct get turned down, simply because the patch that is sent (or commited), is too long for a proper review. In a perfect world, would you have gotten this feedback as you went along, perhaps, but this isn't a perfect world, people are busy, and have other things to do. The fact is your getting this feedback now, and you have seem to have no arguments to technically backup your commit. This is nothing against you personally, I'm not meaning to attack you, but if the code doesn't jive, it shouldn't be in the repository, I'm sorry if you feel like you've wasted effort, but that doesn't change the facts. -Sterling -- PHP
[PHP-DEV] Rand
I am really furious now, and this is why: * People here seem to read things here VERY selectively. On August 4th I submitted a first proposal, and Rasmus (and ONLY Rasmus) had some problems with it, being that this would break BC if ppl rely on the reproducibilty of rand() sequences. THAT WAS THE ONLY COMMENT I GOT. * On August 16th, I submitted a second proposal, which *IMHO* adressed this issue. It went a bit more complex of course, but I was hoping to get that out of the code ASAP, i.e. with the next compatibility breaking PHP. The code also IMPROVED because there was now, unlike the first proposal, a PORTABLE and CLEAR and EXPLICIT way of getting a reproducable sequence of 'random' numbers. Noone commented, even after multiple reminders. By means of (sometimes personal) mails with some phpdev, I got the idea that those ppl agreed with me. * On August 22th, I announced to branch ext/standard to start implementing the changes. IF SOMEONE HAD PROBLEMS WITH THE CHANGES AN-SICH, HE SHOULD HAVE SAID IT AT THAT MOMENT. You couldn't have missed the announcment, since there was a small discussion with Zeev about the branching. * On August 26th, (subject rand() redesign - please read) I announced that the code was alread looking like something, i.e. the general idea was already clear. I also referred AGAIN to my second proposal. Again, nobody had problems with it. * On September 3rd, I merged it into MAIN. And now, suddenly everybody has problems with both semantics and implementation. I'm stunned. And angry. All the time from August 22th until September 3rd, you also could have seen CVS-commit messages on PHP-CVS. If people are TOO LAZY to read ANY of these mails, they LOOSE IMO the right to comment to the code as it is today on a way that is done now. I have NO PROBLEM at all when ppl say something like On line 123 of rand.c, you do something like this-and-this, wouldn't that-and-that be more efficient/better/elegant/whatever. But I DO HAVE PROBLEMS with the reaction I got so far. So. I suggest people go read and read again the things I referred to above when they want to have something to say about the changes. And only then submit your comments to php-dev. The next few days I won't be able to read mail a lot, so please don't be inpatient - there's a life outside PHP (at least for me). I also suggest we act like there were no mails sent after the merge. Jeroen (and I *definitely* also need some positive reactions otherwise you probably won't see any more patches from me (some people won't care maybe, but that's their problem)) PS: Egon, go read my reply when you asked that the first time. Wasn't I clear? It was in plain English though... -- 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]
Re: [PHP-DEV] Rand Changes
Ok, We're now in a situation that has to be resolved. I think there are 3 issues: - The way php-dev behaved was flawed. While there's truth in what Sterling said about opensource projects, I have to say that the amount Jeroen put into the RFC about the subject is not very common. Thus, I can understand his anger, when php-dev suddenly wakes up after he's done all the work. - After looking at the code, I have to agree with Sterling about the style. Big chunked macros which should be functions, over-all breakage, etc., for something that is, after all, just supposed to return integers. It looks a bit like killing a fly with a cannon. - We can't ignore the fact that a much simpler and even less BC breaking way was offered - simply creating a new function named random(), unfortunately, after the work that's been done. In my opinion, if we combine these three into actions, then: - We owe an apology to Jeroen - We should revert the code and implement the KISS approach by simply introducing a new function. Zeev At 02:34 03-09-01, Sterling Hughes wrote: Howdy, I have a few problems with the latest random number related commits, most importantly being the quality of the underlying code, rather than some of the changes it implements (which are also un-necessary, imho, if it ain't broke -- don't fix it). 1) On a style note, the code makes poor use of macro's, pim_srand_common is a good example of a macro gone wrong.. 2) It's un-optimized, and the code does not follow a logical structure, one indication of this is the PHP_FUNCTION_RAND() and PHP_RAND_RANGE(), which does too much for a macro in this case (and comments like that really don't belong in a macro). Also, folks, don't use register on a variable that will be accessed twice. 3) I don't think the extra level of abstraction is warranted in this case -- it slows things down, it doesn't speed them up, and there is really no great improvement from an API perspective to doing this. 4) What was sooo wrong about the way we were doing things? Even though we don't have a voting system, I'm a strong -1 on this patch. :))) Instead -- changes that I think would be a good idea (and I'll implement these if you don't want to Jeroen) are: a) Making the seed argument optional to [mt_]srand(), and use the most random seed possible if no seed is specified, this is a good way to help out people. b) Update to the php4 api, and remove some of the redundant logic in rand.c pre-patch (well redundant from a PHP4 perspective). -Sterling -- 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] -- 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]
[PHP-DEV] Rand Changes
Howdy, I have a few problems with the latest random number related commits, most importantly being the quality of the underlying code, rather than some of the changes it implements (which are also un-necessary, imho, if it ain't broke -- don't fix it). 1) On a style note, the code makes poor use of macro's, pim_srand_common is a good example of a macro gone wrong.. 2) It's un-optimized, and the code does not follow a logical structure, one indication of this is the PHP_FUNCTION_RAND() and PHP_RAND_RANGE(), which does too much for a macro in this case (and comments like that really don't belong in a macro). Also, folks, don't use register on a variable that will be accessed twice. 3) I don't think the extra level of abstraction is warranted in this case -- it slows things down, it doesn't speed them up, and there is really no great improvement from an API perspective to doing this. 4) What was sooo wrong about the way we were doing things? Even though we don't have a voting system, I'm a strong -1 on this patch. :))) Instead -- changes that I think would be a good idea (and I'll implement these if you don't want to Jeroen) are: a) Making the seed argument optional to [mt_]srand(), and use the most random seed possible if no seed is specified, this is a good way to help out people. b) Update to the php4 api, and remove some of the redundant logic in rand.c pre-patch (well redundant from a PHP4 perspective). -Sterling -- 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]
[PHP-DEV] rand()-redesign - please read
Hi all, The rand()-redesign is already looking like something. The next few days I'm N/A, and I would appreciate it if people who: - possibly have remarks on the new behaviour of rand() co, take a look at my second proposal on this subject: http://marc.theaimsgroup.com/?l=php-devm=99802330332087w=2 - want to guard for correctneat coding in PHP, take a quick look at the RAND_REDESIGN branch. It isn't ready, and it'd be a wonder if it compiles, since I didn't try, but the intention on how it will be coded is quite clear now. And please send any remarks, both positive and negative, to me and/or to php-dev. Because the further it gets, the harder it will be to change it. (and I'm _not_ going to revert anymore...) Thanks a lot, 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]
