random numbers

[Johannes Veerkamp]

hi there,
i'm a newbie in c and i'd like to write a programm which generates random
numbers from 1 to 10 (integers). can anybody help me out with the correct
code?

thanx

 

[Johannes Veerkamp]

it's me again, i answered the question myself, but can anybody tell me
why the programm always generates the same numbers when executing it??

thanks

 

[Christopher Benson-Manica]

it's me again, i answered the question myself, but can anybody tell me
why the programm always generates the same numbers when executing it??

Well, besides invoking the wrath of He Who Holds In Thrall on line 42,
you might be misusing rand() - rand() requires a unique seed to give
you anything remotely like random numbers (key word: "remotely").
Check out srand() if that sounds relevant. Otherwise, the Conclave of
C Cages (soft 'c') will be much more able to help you if you actually
describe your code and/or post it.

 

[Johan Lindh]

it's me again, i answered the question myself, but can anybody tell me
why the programm always generates the same numbers when executing it??

thanks

The rand function returns a pseudorandom integer in the range 0 to
RAND_MAX. Use the srand function to seed the pseudorandom-number
generator before calling rand.

Read your C book. It's all in there.

/J

 

[Eric Sosman]

it's me again, i answered the question myself, but can anybody tell me
why the programm always generates the same numbers when executing it??

The two questions you have asked are both covered in
the comp.lang.c Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

 

[Robert]

Check this out.. from glibc manual.

"If you want to generate a random integer between 1
and 10, you should always do it by using high-order
bits, as in

j=1+(int) (10.0*rand()/(RAND_MAX+1.0));

and never by anything resembling

j=1+(rand() % 10);

(which uses lower-order bits)."

 

[Sidney Cadot]

it's me again, i answered the question myself, but can anybody tell me
why the programm always generates the same numbers when executing it??

Show us the program, it helps.

Assuming you use rand(): the random generator in C actually generates a
"pseudo-random" sequence. This is for two reasons:

1) without an external source of randomness (e.g., particular types
hardware, or timed user events) it is /fundamentally impossible/ for a
computer to generate truly random numbers, since the computer must use a
(deterministic) algorithm.

2) it is actually convenient to be able to re-generate the same sequence
all over again. Suppose you do a simulation that uses rand() and at some
point, you see something weird happening. Thanks to the repeatability of
the sequence, you can reproduce the phenomenon.

If you don't like this behavior, look into the srand() function; it is
possible to use an external value as a seed (e.g., the process id, or
the time) to get a non-reproducible sequence. This is hardly ever a good
idea though.

Best regards,

Sidney

 

[Sidney Cadot]

Check this out.. from glibc manual.

"If you want to generate a random integer between 1
and 10, you should always do it by using high-order
bits, as in

j=1+(int) (10.0*rand()/(RAND_MAX+1.0));

and never by anything resembling

j=1+(rand() % 10);

(which uses lower-order bits)."

If you want to generate a pseudo-random sequence portably with
predictable properties, you have little choice other than to implement
one yourself. There's simply to many bad random generators out there;
the glibc-snippet addresses just 1 common problem.

Best regards,

Sidney

 

[Gordon Burditt]

Assuming you use rand(): the random generator in C actually generates a

"pseudo-random" sequence. This is for two reasons:

1) without an external source of randomness (e.g., particular types
hardware, or timed user events) it is /fundamentally impossible/ for a
computer to generate truly random numbers, since the computer must use a
(deterministic) algorithm.

The source of randomness doesn't necessarily have to be external.
Some processors have hardware for this on-chip (I believe this
includes the Pentium III). But you DO need hardware designed to
generate randomness, as most of the CPU is carefully designed to
avoid randomness (otherwise the chip is generally called "broken").

According to quantum physics, there are certain things that are
fundamentally random and you can get randomness by measuring them.
A couple of these include radioactive decay, thermal noise from a
diode, and there is some argument for randomness from a complex
system such as a human typing when you do keystroke timing below
the microsecond level.

2) it is actually convenient to be able to re-generate the same sequence
all over again. Suppose you do a simulation that uses rand() and at some
point, you see something weird happening. Thanks to the repeatability of
the sequence, you can reproduce the phenomenon.

If you don't like this behavior, look into the srand() function; it is
possible to use an external value as a seed (e.g., the process id, or
the time) to get a non-reproducible sequence. This is hardly ever a good
idea though.

If your point is that it is hardly ever a good idea to try to
generate a non-reproducible sequence, I'll disagree. A sequence
that doesn't change makes games boring. Try running a casino based
on a random-number generator that starts over using the same sequence.
The gamblers will catch on and you'll go broke. On the other hand,
rand() is not nearly good enough in even a majority of C implementations
to run a casino. For one thing, most versions of rand() don't
generate enough random bits or contain enough internal state (32
bits isn't enough).

Gordon L. Burditt

 

[Peter Pichler]

[...] most of the CPU is carefully designed to
avoid randomness (otherwise the chip is generally called "broken").

<ot>
Overheard in 1995:
Q: Why is pentium so fast?
A: Because it gets the result by guess.
</ot>

Sorry, it's Friday ;-)

 

[Gordon Burditt]

[...] most of the CPU is carefully designed to

<ot>
Overheard in 1995:
Q: Why is pentium so fast?
A: Because it gets the result by guess.
</ot>

Sorry, it's Friday ;-)

As far as I know, Pentium math problems still ended up giving you
the same (sometimes WRONG) answer if you gave it the same numbers
to divide. It's not like it said that 6.0/3.0 is 1.7, no, 2, no
-5, no 2.3, no, 65536, ... .


Gordon L. Burditt