Re: [PHP-DEV] RFC: mt_* functions
Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother, and shouldn't be the concern of the programmer, but rather the system maintainer (specific cases excluded, but than you leave the high-level of PHP, and go to low-level implementation issues.). But they are different in that each will produce a deterministic sequence based on their seeds. If I, as an application developer, distributes a regression test harness which tests my app with a specific seed expecting a specific sequence and the server my app runs on has switched rand() to use the mt_rand() algorithm my regression test will fail. True... though IMHO a regression test is not strictly using PHP in a high-level way, but goes into internal behaviour of it. In the documentation, rand() is defined to return a pseudo-random value between 0 and RAND_MAX. It states nothing about that the same seed yields the same sequence. True, this is the case in (almost) any pseudo-random-generator. But relying on that behaviour is IMO using low-level implementation knowledge. Of course, it is not forbidden to use that knowledge, but if you do, I believe that it is your own responsibility to keep an eye on the changelog when upgrading. And with a rand_generator = system setting, you actually have a guarantee that the system's rand is used, with all it's properties. I'm not denying that this change could break a script (though IMO it would be rare). A solution would be to have it defaulted to 'system', and let the mt_* functions always use mt, regardless of the ini-setting. By default, no result will be different then, while still rand()'s behaviour is determined by an ini-setting. In the end, it'd be best (IMO) to switch the default to mt, and that change - though with less impact - has technically the same consequences as turning register_globals off by default. This is somewhat like saying that we should make crypt() just be an alias for md5() since md5() is a better algorithm. The fact that it is better is rather irrelevant since the output of the algorithm itself is sometimes important. Many times you can swap crypt() for md5(), but many times you can't. Same goes for rand() and mt_rand(). 'somewhat like', indeed, since crypt is defined to use DES, and is targetted at being the same on the same input. This definitely not the case with rand(), it is a regretful consequence of the way computers work why it sometimes can be predicted. -Rasmus 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] RFC: mt_* functions
[[EMAIL PROTECTED]] Hi, Currently, the rand_functions all have mt_ clones, which use a in-PHP-implementation (Mersenne-Twister) rather than an external implementation. This is IMHO a bit strange way of chosing between implementation. My suggestion is to make it only one familiy of functions, the implementation of which is determined by an ini-entry. (rand = system vs. rand = mt, or something like that, default: mt). The functionality is the same (*), and IMO it's a per-system-decision wether you want to use the mt-algorithms or the system ones. (usually mt, unless your system has a real good / very special one) For backwards compatibility, mt_* can be aliased to their normal equivalents. Please don't. Ini settings that change semantics are a bother, and people should be able to choose their random function. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] RFC: mt_* functions
At 11:15 PM 8/4/2001 +0200, Stig Sæther Bakken wrote: [[EMAIL PROTECTED]] Hi, Currently, the rand_functions all have mt_ clones, which use a in-PHP-implementation (Mersenne-Twister) rather than an external implementation. This is IMHO a bit strange way of chosing between implementation. My suggestion is to make it only one familiy of functions, the implementation of which is determined by an ini-entry. (rand = system vs. rand = mt, or something like that, default: mt). The functionality is the same (*), and IMO it's a per-system-decision wether you want to use the mt-algorithms or the system ones. (usually mt, unless your system has a real good / very special one) For backwards compatibility, mt_* can be aliased to their normal equivalents. Please don't. Ini settings that change semantics are a bother, and people should be able to choose their random function. +1 for the -1 (does that equal 0?) -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]
Re: [PHP-DEV] RFC: mt_* functions
Please don't. Ini settings that change semantics are a bother, and people should be able to choose their random function. Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother, and shouldn't be the concern of the programmer, but rather the system maintainer (specific cases excluded, but than you leave the high-level of PHP, and go to low-level implementation issues.). - Stig 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] RFC: mt_* functions
Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother, and shouldn't be the concern of the programmer, but rather the system maintainer (specific cases excluded, but than you leave the high-level of PHP, and go to low-level implementation issues.). But they are different in that each will produce a deterministic sequence based on their seeds. If I, as an application developer, distributes a regression test harness which tests my app with a specific seed expecting a specific sequence and the server my app runs on has switched rand() to use the mt_rand() algorithm my regression test will fail. This is somewhat like saying that we should make crypt() just be an alias for md5() since md5() is a better algorithm. The fact that it is better is rather irrelevant since the output of the algorithm itself is sometimes important. Many times you can swap crypt() for md5(), but many times you can't. Same goes for rand() and mt_rand(). -Rasmus -- 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] RFC: mt_* functions
On Sat, 4 Aug 2001, Rasmus Lerdorf wrote: based on their seeds. If I, as an application developer, distributes a regression test harness which tests my app with a specific seed expecting a specific sequence and the server my app runs on has switched rand() to use the mt_rand() algorithm my regression test will fail. So, if you always use mt_rand() you should be okay? Since the algorithm for rand() might be different from system to system..? --Jani -- 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] RFC: mt_* functions
On Sat, 4 Aug 2001, Rasmus Lerdorf wrote: based on their seeds. If I, as an application developer, distributes a regression test harness which tests my app with a specific seed expecting a specific sequence and the server my app runs on has switched rand() to use the mt_rand() algorithm my regression test will fail. So, if you always use mt_rand() you should be okay? Since the algorithm for rand() might be different from system to system..? Sure, although rand() tends to be the same everywhere as well. At least on all the systems I care about it is the same. Linux, FreeBSD, OpenBSD and Solaris all seem to use the same algorithm. -Rasmus -- 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] RFC: mt_* functions
On Sat, 4 Aug 2001, Rasmus Lerdorf wrote: On Sat, 4 Aug 2001, Rasmus Lerdorf wrote: based on their seeds. If I, as an application developer, distributes a regression test harness which tests my app with a specific seed expecting a specific sequence and the server my app runs on has switched rand() to use the mt_rand() algorithm my regression test will fail. So, if you always use mt_rand() you should be okay? Since the algorithm for rand() might be different from system to system..? Sure, although rand() tends to be the same everywhere as well. At least on all the systems I care about it is the same. Linux, FreeBSD, OpenBSD and Solaris all seem to use the same algorithm. Then why do some people have troubles with rand() on Solaris? :) Or is it some specific version of it? --Jani -- 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] RFC: mt_* functions
Sure, although rand() tends to be the same everywhere as well. At least on all the systems I care about it is the same. Linux, FreeBSD, OpenBSD and Solaris all seem to use the same algorithm. Then why do some people have troubles with rand() on Solaris? :) Or is it some specific version of it? No idea. -Rasmus -- 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]
