Hi lug-dd,
ich hab hier immer noch den Loszettel von der Pentacon-Mietloehnung rumfliegen. Es steht auch ne Nummer drauf, die ich natuerlich nicht verrate :)
Nun sollte ja ein Zufallsgenerator ueber die Vergabe des Posters entscheiden. Hier eine bash-only Loesung (kommt ausschliesslich mit bash-Builtins aus). Ja, ich bin Shellskripting Fan ;-)
-------------------------------schnipp----------------------------
#!/bin/bash # limit=300 # # generate a random time seed from user interaction # IFS=". " read x tstart x < /proc/uptime IFS=" " i=9 while [ $i -gt 0 ] do x="" while [ -z "$x" ] do echo -n "$i: type something and press [RETURN]: " read x done i=$[i-1] done IFS=". " read x tstop x < /proc/uptime IFS=" " dryrun=$[tstart+tstop] # # now do a "dry run" to based on time seed # i=0 while [ $i -lt $dryrun ] do x=$RANDOM i=$[i+1] done # # take a guess at the interval $RANDOM numbers are in # sum=0 i=0 while [ $i -lt 50 ] do sum=$[sum+RANDOM/50] i=$[i+1] done if [ ${#sum} -gt 8 ] ; then maxrand=2147483647 else maxrand=32767 fi # # we can only do integer division # div=$[maxrand/limit] # # now generate the actual random number # winner=$[RANDOM/div] echo "And the winner is: $winner"
-------------------------------schnapp----------------------------
Wieviele Lose hatten wir eigentlich?
bye, Chris
On Wednesday 18 July 2001 15:59, Christian Perle wrote:
Hi lug-dd,
ich hab hier immer noch den Loszettel von der Pentacon-Mietloehnung rumfliegen. Es steht auch ne Nummer drauf, die ich natuerlich nicht verrate :)
Nun sollte ja ein Zufallsgenerator ueber die Vergabe des Posters entscheiden. Hier eine bash-only Loesung (kommt ausschliesslich mit bash-Builtins aus). Ja, ich bin Shellskripting Fan ;-)
-------------------------------schnipp---------------------------- -------------------------------schnapp----------------------------
Wieviele Lose hatten wir eigentlich?
272, aber um es wirklich gemein zu machen wird nur ein Bruchteil davon verteilt werden - welche das sind wird in einer ASCII-Datei stehen (kann man ja mit wc -w auswerten).
Konrad
PS.: ganz toll wäre, wenn das Script eine Webpage mit allen Vorhandenen und der ausgewählten Nummer ausgäbe... die könnte man dann gleich auf den Server stellen.
On Wed, Jul 18, 2001 at 06:21:45PM +0200, Konrad Rosenbaum wrote:
Konrad
PS.: ganz toll wäre, wenn das Script eine Webpage mit allen Vorhandenen und der ausgewählten Nummer ausgäbe... die könnte man dann gleich auf den Server stellen.
Eine Teillösung: eine zufällige Zeile aus der Datei mit Losnummern:
#! /bin/bash LOSE=lose set -- $(wc -l $LOSE) sed -n "$(expr $RANDOM % $1 + 1)p" $LOSE
Best regards from Dresden/Germany Viele Gruesse aus Dresden Heiko Schlittermann
Hi Heiko,
On Wed, Jul 18, 2001 at 18:40:43 +0200, Heiko Schlittermann wrote:
sed -n "$(expr $RANDOM % $1 + 1)p" $LOSE
Das Random-Intervall mit Modulo einschraenken wirkt sich AFAIK ziemlich uebel auf die Verteilung aus. Siehe auch man random(3).
bye, Chris
On Wed, Jul 18, 2001 at 06:51:23PM +0200, Christian Perle wrote: Abend!
sed -n "$(expr $RANDOM % $1 + 1)p" $LOSE
Das Random-Intervall mit Modulo einschraenken wirkt sich AFAIK ziemlich uebel auf die Verteilung aus. Siehe auch man random(3).
Nur wenn die Zufallszahlen, von denen man den modulo nimmt, schlecht sind. Das is IMO gerade ein Test für die Qualität von (Pseudo)-ZZGeneratornen. Gute ZZ sollten also auch nach mod n nicht weniger gleichmäßig verteilt sein als vorher.
in man random(3) finde ich übrigens nichts dazu.
Reinhard
Hi Reinhard,
On Wed, Jul 18, 2001 at 20:53:26 +0200, Reinhard Foerster wrote:
schlecht sind. Das is IMO gerade ein Test für die Qualität von (Pseudo)-ZZGeneratornen. Gute ZZ sollten also auch nach mod n nicht weniger gleichmäßig verteilt sein als vorher.
in man random(3) finde ich übrigens nichts dazu.
Sorry, ich meinte man rand(3):
"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)."
bye, Chris
On Wed, Jul 18, 2001 at 09:21:36PM +0200, Christian Perle wrote:
Hi Christian,
"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)."
Mhh. Trotzdem komisch. Ich meine mal gelernt zu haben, daß es heutzutage genug PZZGs gibt, bei denen nicht die oberen Bits besser sind als die unteren.
Reinhard
On Wed, Jul 18, 2001 at 09:43:01PM +0200, Reinhard Foerster wrote:
Mhh. Trotzdem komisch. Ich meine mal gelernt zu haben, daß es heutzutage genug PZZGs gibt, bei denen nicht die oberen Bits besser sind als die unteren.
... und lies mal etwas weiter oben in man rand(3):
The versions of rand() and srand() in the Linux C Library use the same random number generator as random() and sran dom(), so the lower-order bits should be as random as the higher-order bits. However, on older rand() implementa tions, the lower-order bits are much less random than the higher-order bits.
Damit ist des Verkleinern des Bereichs per modulo wohl unproblematisch.
Reinhard
On Wednesday 18 July 2001 21:21, Christian Perle wrote:
Hi Reinhard,
On Wed, Jul 18, 2001 at 20:53:26 +0200, Reinhard Foerster wrote:
schlecht sind. Das is IMO gerade ein Test für die Qualität von (Pseudo)-ZZGeneratornen. Gute ZZ sollten also auch nach mod n nicht weniger gleichmäßig verteilt sein als vorher.
in man random(3) finde ich übrigens nichts dazu.
Sorry, ich meinte man rand(3):
[cut]
soweit ich weiß gilt das nur für den Algo hinter einigen älteren Implementationen von rand(3), nicht aber für random(3). Soweit ich weiß sind unter Linux beide Algorithmen vernünftig verteilt. Beides sollte also für unsere Zwecke reichen (auch mit Modulo statt Division), wenn wir das Programm auf Linux ausführen (ich geh' mal davon aus).
Zitat aus der selben Manpage: --- The versions of rand() and srand() in the Linux C Library use the same random number generator as random() and srandom(), so the lower-order bits should be as random as the higher-order bits. However, on older rand() implementations, the lower-order bits are much less random than the higher-order bits. ---
Konrad
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Heiko Schlittermann -
konrad.rosenbaum＠t-online.de -
Reinhard Foerster