On Sun, 2 Feb 2003 [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
> >On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
> >>
> >> Anyway, last time we discussed this, I think we stuck with the rand()
> >> we had because we feared that people were using it's repeatable well
> >> documented sequence of random numbers in regression testing.
> >
> >As documented, it must be repeatable across the calls for same seed, that
> >is all. It not means repeatable accross platforms or across different OS
> >versions. In fact it is already not repeatable across different OS'es, so
> >regression is limited. Also, regression must not stop bugs fixing progress
> >in anycase.
>
> Our manual pages do not comprehensively list all compatibility
> concerns or concessions, waving our manpage about does not address
> the concern.
>
> As I said, I don't know how big a concern this is. But last time
> it was enough of a concern to make us keep rand() as it was.
>
man srand on another system (for what its worth) says:
The rand() function uses a multiplicative congruential
random-number generator with period 2**32 that returns suc-
cessive pseudo-random numbers in the range of 0 to RAND_MAX
(defined in <stdlib.h>).
The srand() function uses the argument seed as a seed for a
new sequence of pseudo-random numbers to be returned by sub-
sequent calls to rand(). If srand() is then called with the
same seed value, the sequence of pseudo-random numbers will
be repeated. If rand() is called before any calls to
srand() have been made, the same sequence will be generated
as when srand() is first called with a seed value of 1.
> Please surf the mail-archives to find the discussion, it contained
> a lot of good arguments from both sides, arguments which should
> be thought about before changing rand().
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
