From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] random() function produces wrong range |
Date: | 2000-08-02 14:07:48 |
Message-ID: | 362.965225268@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> The Linux man pages indicate that the behavior and underlying
> implementation of random() and rand() are the same (so I just picked
> one).
Ah, well, there's your problem. Whoever did this part of the library
on Linux took shortcuts. On older-line systems, rand() is a
considerably older and crummier generator than random(). It would
definitely not be a wise decision to use rand() instead.
It appears that on SysV-heritage machines, rand() delivers 15-bit
results (which is what I'm getting) whereas on BSD-heritage platforms
it produces 31-bit results. But even the BSD machines say
The spectral properties of rand() leave a great deal to be
desired. drand48(3) and random(3) provide much better,
though more elaborate, random-number generators.
(quote from SunOS 4.1 man page for rand()).
I believe using random() is the right thing. The portability bug here
is the assumption that RAND_MAX applies to random() (or is even defined;
none of the man pages I've looked at so far mention it). But all the
machines say that the output of random() is 31 bits, so INT_MAX should
work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Malcolm Beattie | 2000-08-02 14:21:45 | Re: random() function produces wrong range |
Previous Message | jeff seaman | 2000-08-02 13:27:41 | user authentication question |
From | Date | Subject | |
---|---|---|---|
Next Message | Malcolm Beattie | 2000-08-02 14:21:45 | Re: random() function produces wrong range |
Previous Message | Larry Rosenman | 2000-08-02 13:39:16 | RE: mac.c |