Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Generating random numbers

37 views
Skip to first unread message

GotDibs

unread,
Feb 17, 2002, 12:19:26 PM2/17/02
to
How do I generate random numbers? I tried using rand(), but get the same
numbers every time a run the program. I tried using srand(), but get the
following messages when trying to compile:
----
random.c:16: too few arguments to function `srand'
random.c:16: void value not ignored as it ought to be
----


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Ben Pfaff

unread,
Feb 17, 2002, 1:08:19 PM2/17/02
to
"GotDibs" <dher...@discover-net.net> writes:

> How do I generate random numbers? I tried using rand(), but get the same
> numbers every time a run the program. I tried using srand(), but get the
> following messages when trying to compile:
> ----
> random.c:16: too few arguments to function `srand'
> random.c:16: void value not ignored as it ought to be
> ----

Read the FAQ. This might also be helpful:

By default, the C random number generator produces the same
sequence every time the program is run. In order to generate
different sequences, it has to be "seeded" using srand() with a
unique value. The function below to do this is carefully
designed. It uses time() to obtain the current time; the
alternative clock() is a poor choice because it measures CPU time
used, which is often more or less constant among runs. The
actual value of a time_t is not portable, so it computes a "hash"
of the bytes in it using a multiply-and-add technique. The
factor used for multiplication normally comes out as 257, a prime
and therefore a good candidate.

References: Knuth, _The Art of Computer Programming, Vol. 2:
Seminumerical Algorithms_, section 3.2.1; Aho, Sethi, and Ullman,
_Compilers: Principles, Techniques, and Tools_, section 7.6.

#include <limits.h>
#include <stdlib.h>
#include <time.h>

/* Choose and return an initial random seed based on the current time.
Based on code by Lawrence Kirby <fr...@genesis.demon.co.uk>.
Usage: srand (time_seed ()); */
unsigned
time_seed (void)
{
time_t timeval; /* Current time. */
unsigned char *ptr; /* Type punned pointed into timeval. */
unsigned seed; /* Generated seed. */
size_t i;

timeval = time (NULL);
ptr = (unsigned char *) &timeval;

seed = 0;
for (i = 0; i < sizeof timeval; i++)
seed = seed * (UCHAR_MAX + 2u) + ptr[i];

return seed;
}

--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan

pete

unread,
Feb 17, 2002, 2:16:24 PM2/17/02
to
GotDibs wrote:

> random.c:16: too few arguments to function `srand'

#include <stdlib.h>
#include <time.h>

srand((unsigned)time(NULL));

--
pete

Stig Brautaset

unread,
Feb 17, 2002, 2:07:13 PM2/17/02
to
In article <87664wx...@pfaff.stanford.edu>, Ben Pfaff wrote:
> "GotDibs" <dher...@discover-net.net> writes:
>
>> How do I generate random numbers? I tried using rand(), but get the same
>> numbers every time a run the program. I tried using srand(), but get the
>> following messages when trying to compile:
>> ----
>> random.c:16: too few arguments to function `srand'
>> random.c:16: void value not ignored as it ought to be
>> ----
>
> Read the FAQ. This might also be helpful:
>
> By default, the C random number generator produces the same
> sequence every time the program is run. In order to generate
> different sequences, it has to be "seeded" using srand() with a
> unique value. The function below to do this is carefully
> designed. It uses time() to obtain the current time; the
> alternative clock() is a poor choice because it measures CPU time
> used, which is often more or less constant among runs. The
> actual value of a time_t is not portable, so it computes a "hash"
> of the bytes in it using a multiply-and-add technique. The
> factor used for multiplication normally comes out as 257, a prime
> and therefore a good candidate.

Ok, I'm intrigued. I more or less understood this function of yours, but
there is one thing I don't understand. If a prime is preferrable, then
(just out of interest) why don't you make the factor a constant of 257
(or any other prime)? Is it to add that little bit of unpredictability?

Stig

Ben Pfaff

unread,
Feb 17, 2002, 2:51:55 PM2/17/02
to
Stig Brautaset <stig...@start.no> writes:

If we're on a system with, say, 16-bit `char's, then using 257
will cause seeds to overlap in range more than if we used
UCHAR_MAX + 2u. Of course, if UCHAR_MAX == UINT_MAX, UCHAR_MAX +
2u has the value 1, so maybe it would indeed be a good idea to
rethink this idea.
--
"You call this a *C* question? What the hell are you smoking?" --Kaz

Gordon Burditt

unread,
Feb 17, 2002, 3:12:43 PM2/17/02
to
>How do I generate random numbers?

You need hardware support of some kind to generate truly random
numbers. Sometimes this is done by timing keystrokes, measuring
thermal noise from a diode, measuring radioactive decay, or similar
means. It is still very difficult to do this without introducing
bias (for example, power line hum tends to get into everything).

Software "random number generators" generate pseudo-random numbers.
It can't generate really random numbers without hardware support
unless the computer is broke. Some CPUs have random-number support
built in. In cryptography, the difference between pseudo-random
numbers and truly random numbers may mean the difference between
life (out of prison) and death.

Read the documentation on rand() and srand(). srand() is *NOT*
intended to return random numbers as a return value.

Gordon L. Burditt

CBFalconer

unread,
Feb 17, 2002, 5:19:25 PM2/17/02
to
Gordon Burditt wrote:
>
... snip ...

>
> Read the documentation on rand() and srand(). srand() is *NOT*
> intended to return random numbers as a return value.

In addition rand and srand have different detailed effects on
different systems. If you want your PNG to generate repeatable or
randomized sequences, so you can do proper testing, install your
own. I am using cokusMT for the purpose, which generates an
extremely long sequence. Most repeat in something like 32768
calls.

--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)


Lawrence Kirby

unread,
Feb 17, 2002, 4:57:23 PM2/17/02
to
On 17 Feb, in article <87it8vx...@pfaff.stanford.edu>
b...@cs.stanford.edu "Ben Pfaff" wrote:

>Stig Brautaset <stig...@start.no> writes:
>
>> In article <87664wx...@pfaff.stanford.edu>, Ben Pfaff wrote:
>> > By default, the C random number generator produces the same
>> > sequence every time the program is run. In order to generate
>> > different sequences, it has to be "seeded" using srand() with a
>> > unique value. The function below to do this is carefully
>> > designed. It uses time() to obtain the current time; the
>> > alternative clock() is a poor choice because it measures CPU time
>> > used, which is often more or less constant among runs. The
>> > actual value of a time_t is not portable, so it computes a "hash"
>> > of the bytes in it using a multiply-and-add technique. The
>> > factor used for multiplication normally comes out as 257, a prime
>> > and therefore a good candidate.
>>
>> Ok, I'm intrigued. I more or less understood this function of yours, but
>> there is one thing I don't understand. If a prime is preferrable, then
>> (just out of interest) why don't you make the factor a constant of 257
>> (or any other prime)? Is it to add that little bit of unpredictability?

It isn't so much unpredictability that is needed for the seed as
maximising the likelihood of prducing a unique value. It is the job of the
PRNG algorithm itself to simulate "unpredictabilty".

The algorithm needs to ensure that all bits in the representation of
the input value contribute to the result (because we don't know which
bits are varying) and also work reasonably when time_t either larger
or smaller than unsigned int.

>If we're on a system with, say, 16-bit `char's, then using 257
>will cause seeds to overlap in range more than if we used
>UCHAR_MAX + 2u.

It can cause more time_t values to map onto the same unsigned int value
which is the opposite of what we want.

>Of course, if UCHAR_MAX == UINT_MAX, UCHAR_MAX +
>2u has the value 1, so maybe it would indeed be a good idea to
>rethink this idea.

That't not a problem because if UCHAR_MAX==UINT_MAX then the possible
results are distributed over the whole range of unsigned int which is
the best we can do. The result still depends on all of the bits of the
representation of the input value.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------

0 new messages