| 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: | Whole Thread | Raw Message | 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 |