Re: 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