Re: Note added to rand

> Note added by joey, > text: > My vote: +0 > Suggestions/remarks: > I'll take the proposal one piece at a time: Good idea :-) > float random() / int random(min, max): > If I understand correctly, the only way you'll know what kind of > return the user is expecting is by counting args. That means if I > just want a random number between LONG_MIN and LONG_MAX (what I expect > *most* users of a "random" fuction are looking for), I have to use the > longer format of random(min, max). This seems counter-intuitive... > The most commonly used version should be the easiest to type. I'd > rather see another function entirely for floats. O yes... oversight, indeed. It was a quick idea which I typed in... indeed, a separate function would be better. I thought that you should always give a range because it otherwise makes no sense. But indeed, LONG_MIN ... LONG_MAX does make sense. > set_random(): > This seems to be to go out of it's way to bring things back to the > way they currently are. If they want to change the algorithm, and the > algorithm is decided via an ini switch, they can use ini_set/ini_alter(). > The primary goal here is to make it possible through a single function > call to obtain a random number, is it not? Let random() seed itself. I wasn't clear. Usually, you do NOT call set_random(), indeed, ini-set is the way it is supposed to be. The only circumstance where you need set_random is when you want a specific seed&algorithm, for example while debugging, place it at the top of the script and you'll get identical numbers each call. > > There is a good idea here, IMHO, and that is to reduce the namespace > by wrapping all possible PRNG's with a very thin wrapper, but I don't > see any need to break BC or make this wrapper any "fatter" than it > needs to be to serve the purpose. I'll return to this and the rest later, I need to go now, I'm supposed to assist in a workgroup... --Jeroen > I'd rather see: > > new ini switch: rand_algoritm, defaults to "mt". (I still think that > mt is probably the best for most people, but I know that some people > disagree...) > > new function: int random() : The same as if user called the desired > rand() algoritm from user-space, with the added benefit of insuring > that a sufficently unique seed has been provided first. > > I don't see a need for any of the rest of this, but I have said before > that I'm really not very good at evaluating things from a "Design" > point of view...I'm much better at evaluating implementations to judge > how well the *fit* the proposed design.