From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 06:10:34 |
Message-ID: | 3987BB5A.AE063C9C@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> The comment in the random() function indicates that its author thought
> it'd produce output in the range 0..1, which seems like a pretty
> reasonable definition:
> Unfortunately, at least on my box, it produces no such thing. random()
> actually yields values in the range 0..2^31-1 --- while RAND_MAX is
> only 32767, because it applies to the rand() function not random().
> So what I actually get is floating-point output in the range 0..65535.
> This is, to say the least, a bizarre definition.
Or, a bizarre machine. Linux (where I did the testing) produces the
expected result.
> I would like to propose changing the code to
> /* result 0.0-1.0 */
> result = ((double) random()) / INT_MAX;
Erk...
Actually, I depend on the behavior being as advertised, which is what
you would have expected. This is true on Linux boxes from RedHat-5.2 to
Mandrake-7.1. Not sure why your machine is different, but if there is a
more portable way to define this let's find it. Otherwise, get used to
#ifdef HPUX ;)
The Linux man pages indicate that the behavior and underlying
implementation of random() and rand() are the same (so I just picked
one). Would it be better to try using rand() instead?
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Jerome Raupach | 2000-08-02 07:55:20 | copy with libpq? |
Previous Message | KMiller | 2000-08-01 22:55:15 | 1763 pq_flush messages |
From | Date | Subject | |
---|---|---|---|
Next Message | Guo Bin | 2000-08-02 06:54:44 | Re: random() function produces wrong range |
Previous Message | Alex Pilosov | 2000-08-02 03:06:44 | Re: mac.c |