---

Hej

Jeg skal automatisk lave et tilfældigt tal mellem 1 og 10. Hvordan gør jeg
det lettest?

Thomas

---

"Thomas" <asd@asd.de> writes:

> Jeg skal automatisk lave et tilfældigt tal mellem 1 og 10. Hvordan gør jeg
> det lettest?

Fra rand(3):

In Numerical Recipes in C: The Art of Scientific Computing (William H.
Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New
York: Cambridge University Press, 1992 (2nd ed., p. 277)), the follow-
ing comments are made:
"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)."

Random-number generation is a complex topic. The Numerical Recipes in
C book (see reference above) provides an excellent discussion of prac-
tical random-number generation issues in Chapter 7 (Random Numbers).


--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

> "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)."

Hmm.. Jeg har aldrig fattet hvorfor nogle bits skulle være mere
"tilfældige" end andre!? Jeg regnede med at en random funktion
normalt var uniform (altså at der er lige stor chance for alle
tal i intervallet 0 - RAND_MAX), og der derfor ikke var påviselig
forskel på de forskellige bits i resultatet. Hvis rand() normalt
ikke er uniform, hvilke regler er den så styret af?

---

> Hmm.. Jeg har aldrig fattet hvorfor nogle bits skulle være mere
> "tilfældige" end andre!? Jeg regnede med at en random funktion
> normalt var uniform (altså at der er lige stor chance for alle
> tal i intervallet 0 - RAND_MAX), og der derfor ikke var påviselig
> forskel på de forskellige bits i resultatet. Hvis rand() normalt
> ikke er uniform, hvilke regler er den så styret af?

Denne problematik med hvikle bits i rand(), som er bedst fik mig
til at lave et lille test-program, som undersøger om det er
forskel på de forskellige bits i rand()s resultat.

Det jeg gør er at se hvormange gange hver bit er sat i rand()s
resultat for en stor mængde rand()-kald. Hvis rand() er uniform,
skulle man få 50% sat og 50% ikke sat for hver bit.

Her er source kode og resultat for Visual C++ .NET:

<code>
#include <stdio.h>
#include <stdlib.h>

static const int ITERATIONS = 1000000;
static const int BITS = 15;

int main(int argc, char *argv[])
{
int i, j, n;
int count[BITS];

// Output RAND_MAX constant
printf("RAND_MAX = %d\n\n", RAND_MAX);

// Initialize count array
for (j = 0; j < BITS; j++)
count[j] = 0;

// Count set bits for some rands
for (i = 0; i < ITERATIONS; i++)
{
n = rand();
for (j = 0; j < BITS; j++)
{
if ((n & 0x0001) != 0)
count[j]++;
n >>= 1;
}
}

// Display result
for (j = 0; j < BITS; j++)
printf("Bit %2d: %4d %2.2f%%\n", j, count[j], (float)count[j] / (float)ITERATIONS * 100.0f);

return 0;
}
</code>

Resultat:

RAND_MAX = 32767

Bit 0: 500198 50.02%
Bit 1: 499977 50.00%
Bit 2: 500025 50.00%
Bit 3: 500049 50.00%
Bit 4: 499598 49.96%
Bit 5: 500402 50.04%
Bit 6: 499299 49.93%
Bit 7: 499757 49.98%
Bit 8: 500109 50.01%
Bit 9: 500000 50.00%
Bit 10: 500458 50.05%
Bit 11: 501132 50.11%
Bit 12: 500248 50.02%
Bit 13: 499928 49.99%
Bit 14: 500080 50.01%

Som man kan se er der ingen forskel på de forskellige bits.. Så jeg
kan ikke se hvorfor man skulle bruge en langsommere float-metode (som
"Numerical Recipes in C" foreslår), når int versionen er ligeså god.
Ihvertfald ikke hvis man bruger Visual C++ .NET

Det forudsætter selvfølgelig at RAND_MAX er (2^n)-1, så man ikke
får "skæve" bits, men hvorfor skulle man dog skrive en rand()-funktion
hvor dette ikke er tilfældet?

---

In <asfj82$jfa$1@sunsite.dk> "Morten F. Hansen" <info@127.0.0.1> writes:

>> Hmm.. Jeg har aldrig fattet hvorfor nogle bits skulle være mere
>> "tilfældige" end andre!? Jeg regnede med at en random funktion
>> normalt var uniform (altså at der er lige stor chance for alle
>> tal i intervallet 0 - RAND_MAX), og der derfor ikke var påviselig
>> forskel på de forskellige bits i resultatet. Hvis rand() normalt
>> ikke er uniform, hvilke regler er den så styret af?

>Denne problematik med hvikle bits i rand(), som er bedst fik mig
>til at lave et lille test-program, som undersøger om det er
>forskel på de forskellige bits i rand()s resultat.

>Det jeg gør er at se hvormange gange hver bit er sat i rand()s
>resultat for en stor mængde rand()-kald. Hvis rand() er uniform,
>skulle man få 50% sat og 50% ikke sat for hver bit.

>Her er source kode og resultat for Visual C++ .NET:

Vel, det er en simpel test og tester ikke ordentlig for tilfaeldighed.
F.x. var bit nummer 0 skiftevis "0" eller "1" i nogle
udgaver af rand(). Det fanger din test f.x. ikke.

/Martin

---

> Vel, det er en simpel test og tester ikke ordentlig for tilfaeldighed.
> F.x. var bit nummer 0 skiftevis "0" eller "1" i nogle
> udgaver af rand(). Det fanger din test f.x. ikke.

Ja, det er korrekt. Det er jeg også kommet til at tænke på. Man må lave
nogle overvejelser om forskellige frekvenser oven i hinanden, som
funktionen svinger med osv. Jeg burde nok sætte mig ned og læse lidt
om random-algoritmer.

---

In <asfl8e$87r$1@sunsite.dk> "Morten F. Hansen" <info@127.0.0.1> writes:

>> Vel, det er en simpel test og tester ikke ordentlig for tilfaeldighed.
>> F.x. var bit nummer 0 skiftevis "0" eller "1" i nogle
>> udgaver af rand(). Det fanger din test f.x. ikke.

>Ja, det er korrekt. Det er jeg også kommet til at tænke på. Man må lave
>nogle overvejelser om forskellige frekvenser oven i hinanden, som
>funktionen svinger med osv. Jeg burde nok sætte mig ned og læse lidt
>om random-algoritmer.

Til orientering:

Clifford A. Pickover har skrevet noget godt om random-generatorer.

Mvh
Martin

---

"Morten F. Hansen" <info@127.0.0.1> wrote in message
news:asfl8e$87r$1@sunsite.dk...
> > Vel, det er en simpel test og tester ikke ordentlig for tilfaeldighed.
> > F.x. var bit nummer 0 skiftevis "0" eller "1" i nogle
> > udgaver af rand(). Det fanger din test f.x. ikke.
>
> Ja, det er korrekt. Det er jeg også kommet til at tænke på. Man må lave
> nogle overvejelser om forskellige frekvenser oven i hinanden, som
> funktionen svinger med osv. Jeg burde nok sætte mig ned og læse lidt
> om random-algoritmer.
>
Kasino-tricket går ud på at satste på sort (eller rød) og fordoble indsatsen
indtil man vinder. Så skulle man være sikker på at vinde. Problemet er at
man meget hurtigt kommer ud i nogle ret store indsatser og man vinder kun et
beløb svarende til den oprindelige indsats. Det havde jeg engang en
lidenskabelig diskussion om over et par juleøl. Jeg satte mig for at skrive
et program som skulle demonstrere at man aldig ville vinde i det lange løb.
Programmet viste det modsatte! Hvad var der galt? Forudsigelig tilfældighed.
sort og rød kom ganske vist lige mange gange (over tid), men sandsynligheden
for at få sort (eller rød) x gange i træk var helt ude i hampen sammenlignet
med samme "teoretiske" sandsynlighed i et kasino. Derfor ville man vinde.
Men sådan er det jo ikke ;) Jeg fik heldigvis skrevet programmet om, så det
viste det jeg ville vise :) Det minder mig om citatet "jeg stoler ikke på en
statistik jeg ikke har været med til at forfalske". Den stædige kamel var
naturligvis heller ikke overbevist.

Det er svært at lade være med at blive filosofisk når man taler
tilfældighed. Er der nu også noget der er tilfældigt?

--
Aksel

---

"Aksel" <aksel@nogoddamnspamformeplease.dk> writes:

> Kasino-tricket går ud på at satste på sort (eller rød) og fordoble indsatsen
> indtil man vinder. Så skulle man være sikker på at vinde. Problemet er at
> man meget hurtigt kommer ud i nogle ret store indsatser og man vinder kun et
> beløb svarende til den oprindelige indsats. Det havde jeg engang en
> lidenskabelig diskussion om over et par juleøl. Jeg satte mig for at skrive
> et program som skulle demonstrere at man aldig ville vinde i det lange løb.
> Programmet viste det modsatte! Hvad var der galt? Forudsigelig tilfældighed.
> sort og rød kom ganske vist lige mange gange (over tid), men sandsynligheden
> for at få sort (eller rød) x gange i træk var helt ude i hampen sammenlignet
> med samme "teoretiske" sandsynlighed i et kasino. Derfor ville man vinde.
> Men sådan er det jo ikke ;) Jeg fik heldigvis skrevet programmet om, så det
> viste det jeg ville vise :) Det minder mig om citatet "jeg stoler ikke på en
> statistik jeg ikke har været med til at forfalske". Den stædige kamel var
> naturligvis heller ikke overbevist.

Hvilken random-funktion/compiler brugte du?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

"Kim Hansen" <k-tahf.qvxh@oek.dk> wrote in message
news:x62n0nj495u.fsf@tyr.diku.dk...
> Hvilken random-funktion/compiler brugte du?
Jeg kan desværre ikke huske det - det er 8-10 år siden (hold * hvor tiden
går). Det har muligvis været turbo pascal og så er det jo helt OT ;)

> --
> Kim Hansen | |\ _,,,---,,_ | Det er ikke
> Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
> 2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
> Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.
Jeg er vild med din mis :)

---

In <asec3h$d6n$1@sunsite.dk> "Morten F. Hansen" <info@127.0.0.1> writes:

>> "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)."

>Hmm.. Jeg har aldrig fattet hvorfor nogle bits skulle være mere
>"tilfældige" end andre!? Jeg regnede med at en random funktion
>normalt var uniform (altså at der er lige stor chance for alle
>tal i intervallet 0 - RAND_MAX), og der derfor ikke var påviselig
>forskel på de forskellige bits i resultatet. Hvis rand() normalt
>ikke er uniform, hvilke regler er den så styret af?

Well, hvis f.x. RAND_MAX er 8 og du tager bit nummer 4 fra hoejre, saa
er den een gang "1" og otte gange "0".

/Martin

---

> Well, hvis f.x. RAND_MAX er 8 og du tager bit nummer 4 fra hoejre, saa
> er den een gang "1" og otte gange "0".

Hmm.. det argumentere jo netop for DET MODSATTE.. Altså at bruge
de LAVE bits og IKKE de høje.

---

"Kim Hansen" <k-tahf.qvxh@oek.dk> wrote in message
news:x627keti6d9.fsf@tyr.diku.dk...
> "Thomas" <asd@asd.de> writes:
>
> > Jeg skal automatisk lave et tilfældigt tal mellem 1 og 10. Hvordan gør
jeg
> > det lettest?
>
> Fra rand(3):
>
> In Numerical Recipes in C: The Art of Scientific Computing (William H.
> Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New
> York: Cambridge University Press, 1992 (2nd ed., p. 277)), the follow-
> ing comments are made:
> "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)."

I de onde gamle dage fandtes der rand implementationer, der var så
exceptionelt elendige, at dette var nødvendigt.

Brug med sindsro rand()%N og gem det andet til historietimerne. Bemærk
dog at hvis N ikke går op i (RAND_MAX+1) så giver det en ikke helt
jævn fordeling, medmindre man tager forholdsregler.

- Anders

---

In <3deb608d$0$71604$edfadb0f@dread11.news.tele.dk> "Anders J. Munch" <andersjm@dancontrol.dk> writes:

>"Kim Hansen" <k-tahf.qvxh@oek.dk> wrote in message
>news:x627keti6d9.fsf@tyr.diku.dk...
>> "Thomas" <asd@asd.de> writes:
>>
>> > Jeg skal automatisk lave et tilfældigt tal mellem 1 og 10. Hvordan gør
>jeg
>> > det lettest?
>>
>> Fra rand(3):
>>
>> In Numerical Recipes in C: The Art of Scientific Computing (William H.
>> Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New
>> York: Cambridge University Press, 1992 (2nd ed., p. 277)), the follow-
>> ing comments are made:
>> "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)."

>I de onde gamle dage fandtes der rand implementationer, der var så
>exceptionelt elendige, at dette var nødvendigt.

>Brug med sindsro rand()%N og gem det andet til historietimerne. Bemærk
>dog at hvis N ikke går op i (RAND_MAX+1) så giver det en ikke helt
>jævn fordeling, medmindre man tager forholdsregler.

Hvorfor dog goere noget forkert, naar det er saa nemt at goere det
rigtigt ?

/Martin

---

"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
> In <3deb608d$0$71604$edfadb0f@dread11.news.tele.dk> "Anders J. Munch"
<andersjm@dancontrol.dk> writes:
>
> >Brug med sindsro rand()%N og gem det andet til historietimerne. Bemærk
> >dog at hvis N ikke går op i (RAND_MAX+1) så giver det en ikke helt
> >jævn fordeling, medmindre man tager forholdsregler.
>
> Hvorfor dog goere noget forkert, naar det er saa nemt at goere det
> rigtigt ?

Hvad er det du mener er forkert?

- Anders

---

In <ZDMG9.53216$HU.3617006@news010.worldonline.dk> "Anders J. Munch" <andersjm@inbound.dk> writes:

>"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
>> In <3deb608d$0$71604$edfadb0f@dread11.news.tele.dk> "Anders J. Munch"
><andersjm@dancontrol.dk> writes:
>>
>> >Brug med sindsro rand()%N og gem det andet til historietimerne. Bemærk
>> >dog at hvis N ikke går op i (RAND_MAX+1) så giver det en ikke helt
>> >jævn fordeling, medmindre man tager forholdsregler.
>>
>> Hvorfor dog goere noget forkert, naar det er saa nemt at goere det
>> rigtigt ?

>Hvad er det du mener er forkert?

rand()%6+1 er forkert.
1+(int) (6.0*rand()/(RAND_MAX+1.0)) er rigtigt.

/Martin

---

"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
> In <ZDMG9.53216$HU.3617006@news010.worldonline.dk> "Anders J. Munch"
<andersjm@inbound.dk> writes:
>
> >"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
> >> In <3deb608d$0$71604$edfadb0f@dread11.news.tele.dk> "Anders J. Munch"
> ><andersjm@dancontrol.dk> writes:
> >>
> >> >Brug med sindsro rand()%N og gem det andet til historietimerne. Bemærk
> >> >dog at hvis N ikke går op i (RAND_MAX+1) så giver det en ikke helt
> >> >jævn fordeling, medmindre man tager forholdsregler.
> >>
> >> Hvorfor dog goere noget forkert, naar det er saa nemt at goere det
> >> rigtigt ?
>
> >Hvad er det du mener er forkert?
>
> rand()%6+1 er forkert.
> 1+(int) (6.0*rand()/(RAND_MAX+1.0)) er rigtigt.

Begge opfylder OPs specifikation. Hvad er det du mener er forkert?

- Anders

---

In <MJRG9.54861$HU.3669779@news010.worldonline.dk> "Anders J. Munch" <andersjm@inbound.dk> writes:

>"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
>> In <ZDMG9.53216$HU.3617006@news010.worldonline.dk> "Anders J. Munch"
><andersjm@inbound.dk> writes:
>>
>> >"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
>> >> In <3deb608d$0$71604$edfadb0f@dread11.news.tele.dk> "Anders J. Munch"
>> ><andersjm@dancontrol.dk> writes:
>> >>
>> >> >Brug med sindsro rand()%N og gem det andet til historietimerne. Bemærk
>> >> >dog at hvis N ikke går op i (RAND_MAX+1) så giver det en ikke helt
>> >> >jævn fordeling, medmindre man tager forholdsregler.
>> >>
>> >> Hvorfor dog goere noget forkert, naar det er saa nemt at goere det
>> >> rigtigt ?
>>
>> >Hvad er det du mener er forkert?
>>
>> rand()%6+1 er forkert.
>> 1+(int) (6.0*rand()/(RAND_MAX+1.0)) er rigtigt.

>Begge opfylder OPs specifikation. Hvad er det du mener er forkert?

OP(?) bad om tilfaeldige tal og rand()%6+1 giver ikke saa gode
tal-sekvenser som 1+(int) (6.0*rand()/(RAND_MAX+1.0)).

Er vi ikke enige om det ?

/Martin

---

"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev i en meddelelse
news:asij20$9ua$1@news.net.uni-c.dk...
> In <MJRG9.54861$HU.3669779@news010.worldonline.dk> "Anders J. Munch"
<andersjm@inbound.dk> writes:
>
> >"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
> >> In <ZDMG9.53216$HU.3617006@news010.worldonline.dk> "Anders J. Munch"
> ><andersjm@inbound.dk> writes:
> >>
> >> >"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
> >> rand()%6+1 er forkert.
> >> 1+(int) (6.0*rand()/(RAND_MAX+1.0)) er rigtigt.
>
> >Begge opfylder OPs specifikation. Hvad er det du mener er forkert?
>
> OP(?) bad om tilfaeldige tal og rand()%6+1 giver ikke saa gode
> tal-sekvenser som 1+(int) (6.0*rand()/(RAND_MAX+1.0)).
>
> Er vi ikke enige om det ?

Jeg ved faktisk ikke hvad du mener. Taler du om det med de lave bit,
som så vidt jeg er informeret er en historisk betinget myte? Eller
taler du om det med fordelingen hvis N ikke går op i RAND_MAX+1, som
floating-point versionen i øvrigt også lider under?

OP = original poster.

mvh. Anders

---

In <SR6H9.55180$HU.3752216@news010.worldonline.dk> "Anders J. Munch" <andersjm@inbound.dk> writes:

>"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev i en meddelelse
>news:asij20$9ua$1@news.net.uni-c.dk...
>> In <MJRG9.54861$HU.3669779@news010.worldonline.dk> "Anders J. Munch"
><andersjm@inbound.dk> writes:
>>
>> >"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
>> >> In <ZDMG9.53216$HU.3617006@news010.worldonline.dk> "Anders J. Munch"
>> ><andersjm@inbound.dk> writes:
>> >>
>> >> >"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
>> >> rand()%6+1 er forkert.
>> >> 1+(int) (6.0*rand()/(RAND_MAX+1.0)) er rigtigt.
>>
>> >Begge opfylder OPs specifikation. Hvad er det du mener er forkert?
>>
>> OP(?) bad om tilfaeldige tal og rand()%6+1 giver ikke saa gode
>> tal-sekvenser som 1+(int) (6.0*rand()/(RAND_MAX+1.0)).
>>
>> Er vi ikke enige om det ?

>Jeg ved faktisk ikke hvad du mener. Taler du om det med de lave bit,
>som så vidt jeg er informeret er en historisk betinget myte?

Hvorfor ikke bare bruge den metoden, som _altid_ giver et godt resultat ?
Det er da dumt at bruge en metode som i nogle tilfaelde til give et daarligere
resultat.

>Eller
>taler du om det med fordelingen hvis N ikke går op i RAND_MAX+1, som
>floating-point versionen i øvrigt også lider under?

Vroevl. Det passer ikke.

/Martin

---

"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev:
> In <SR6H9.55180$HU.3752216@news010.worldonline.dk> "Anders J. Munch"
> <andersjm@inbound.dk> writes:
>
> >Eller
> >taler du om det med fordelingen hvis N ikke går op i RAND_MAX+1, som
> >floating-point versionen i øvrigt også lider under?
>
> Vroevl. Det passer ikke.

Oh look this isn't an argument. It's just contradiction.

Kom igen når du er interesseret i at blive klogere.

- Anders

---

tusk@daimi.au.dk (Martin Moller Pedersen) writes:

> Hvorfor ikke bare bruge den metoden, som _altid_ giver et godt
> resultat ? Det er da dumt at bruge en metode som i nogle tilfaelde
> til give et daarligere resultat.

Hvis jeg skal vælge mellem kode der er simpel og let at forstå eller
kode der fungerer godt på gamle Unixen, og koden i begge tilfælde
overholder standarden, vil jeg nok vælge det første.

Det er af samme grund at jeg foretrækker ANSI C. Hvis jeg skulle tage
hensyn til meget gamle Unix versioner, skulle jeg skrive i K&R1 C.

---

> Jeg skal automatisk lave et tilfældigt tal mellem 1 og 10.
> Hvordan gør jeg det lettest?

Du kan bruge rand() og srand() til at lave tilfældige tal med.

Svaret på dit spørgsmål kommer an på om du ønsker heltal (int)
eller komma-tal (float/double) ud.

Her er lidt kode, som kan begge ting:

#include <time.h> // for time()
#include <stdlib.h> // for rand()/srand()

....

// Kald denne funktion een gang når dit program initialiseres.
// Dette gør at du ikke får de samme tal ud hver gang dit
// program køres.
void randomize()
{
srand((unsigned int)time(NULL));
}

// Returnere et tilfældigt tal (int) mellem 0 og range - 1
int irand(int range)
{
return (rand() % range);
}

// Returnere et komma-tal (float) mellem 0 og 1
float frand()
{
return ((float)rand() / (float)RAND_MAX);
}

// Returnere et komma-tal (double) mellem 0 og 1
double drand()
{
return ((double)rand() / (double)RAND_MAX);
}

Hvis du ønsker et heltal mellem 1 og 10 kan du skrive:

int heltal;
heltal = irand(10) + 1;

Hvis du ønsker et komma-tal mellem 1 og 10 kan du skrive:

float komma_tal;
komma_tal = frand() * 9.0f + 1.0f;

Håber det besvarer dit spørgsmål