Discussion:
Zufallsgenerator ungenau
(zu alt für eine Antwort)
@(none)
2004-07-11 17:56:23 UTC
Permalink
Hallo allerseits,

ich wollte mit folgendem Code einen Münzwurf simulieren, allerdings
dürfte das Ganze nicht so klappen wie ich es mir vorgestellt hatte:

java.util.Random lottery = new java.util.Random();

for(int i = 0; i <= 1000; i++) {
System.out.print(lottery.nextInt(2));
}

Es kommen hier überdurchschnittlich oft aufeinanderfolgende
Ziffernketten vor, die in der Praxis so nie auftreten. Zum Beispiel wird
hier eine 1 bis zu 10x hintereinandere geworfen.
Gibt es denn keine bessere Methoden, um Zufallszahlen zu erzeugen?

Mfg,
-Rainer Hahnekamp
Heiner Kücker
2004-07-11 18:23:55 UTC
Permalink
Post by @(none)
ich wollte mit folgendem Code einen Münzwurf simulieren, allerdings
java.util.Random lottery = new java.util.Random();
for(int i = 0; i <= 1000; i++) {
System.out.print(lottery.nextInt(2));
}
Es kommen hier überdurchschnittlich oft aufeinanderfolgende
Ziffernketten vor, die in der Praxis so nie auftreten. Zum Beispiel wird
hier eine 1 bis zu 10x hintereinandere geworfen.
Gibt es denn keine bessere Methoden, um Zufallszahlen zu erzeugen?
Mfg,
-Rainer Hahnekamp
Versuch doch mal Math.random()
Das liefert eine Zufallszahl zwischen 0 und 1.

Die musst Du mit deiner gewünschten Maximal-Grösse multiplizieren.

schöne Grüße aus Essen

Heiner Kücker
Amixstr. 12
Internet: http://www.heiner-kuecker.de
CnC-Demo: http://www.control-and-command.de
Expression-Parser: http://www.heinerkuecker.de/Expression.html
Stefan Matthias Aust
2004-07-11 18:35:57 UTC
Permalink
Post by Heiner Kücker
Versuch doch mal Math.random()
Das liefert eine Zufallszahl zwischen 0 und 1.
Das macht keinen Unterschied, denn Math.random() nutzt auch nur
java.util.Random. Da kann man auch direkt nextDouble() aufrufen oder
besser noch nextBoolean(), da ja nur ein "Münzwurf" gewünscht war. Aber
das nutzt auch nur nextInt() und wir sind wieder am Anfang.

Und an den OP: Random ist halt so gut wie es ist. Wenn ich eine Münze
werfe, kann auch 10x hintereinander "Zahl" kommen. Bei ausreichend
häufiger Anzahl an Versuchen sollte der Erwartungswert für 1 und 0
jeweils bei 50% liegen. Mehr wird glaube ich nicht verlangt. Die Doku
zu Random sagt, dass ein Algorithmus von Knuth benutzt wird. Dort kann
man vielleicht weitere Details nachlesen.

Ich habe mal aufgeschnappt, dass der "Mersenne Twister" ein recht guter
Pseudo-RND-Generator sein soll. Da gibt es garantiert auch was von
Ratiopharm.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Bernd Post
2004-07-11 18:57:36 UTC
Permalink
Ich halte 10x hintereinander denselben boolean für noch nicht
besonders drastisch, wenn ich das richtig überschlage liegt
die Wahrscheinlichkeit dafür stochastisch bei ~0,0009765625
also ungefähr 1:1000 da lohnt sich Lotto spielen wieder ;-).
Zufallszahlen würde ich eher damit umschreiben, daß eine
gleichverteilte 1 Entropie existiert, aber habe noch keine
DIN dazu gesehen, kommt wohl auf die Anwendung an.
Wie wäre es zwei Random mit unterschiedlichen Seeds zu verknüpfen
â la return (random1 == random2). Damit müssten sich doch zumindest
Büschelfehler kaschieren lassen.
Frank Buss
2004-07-11 19:19:31 UTC
Permalink
Post by Bernd Post
Zufallszahlen würde ich eher damit umschreiben, daß eine
gleichverteilte 1 Entropie existiert, aber habe noch keine
DIN dazu gesehen, kommt wohl auf die Anwendung an.
Gibt da verschiedene Methoden, gebräuchlich soll die Chi-Square-Methode
sein. Ich habe da ein Programm gefunden:

http://www.fourmilab.ch/random/

Stürzte mit einer Floating-Point-Exception ab, aber ich habe es neu
compiliert, wenn es einen interessiert:

http://www.frank-buss.de/tmp/ent.exe

Auf 1.000.000 Zahlen, die so generiert wurden:

Random r = new Random();
FileOutputStream f = new FileOutputStream ("c:\\tmp\\t.dat");
for (int i = 0; i < 1000000; i++) {
f.write(r.nextInt(256));
}
f.close();

liefert das Programm diese Ausgabe:

Entropy = 7.999833 bits per byte.

Optimum compression would reduce the size
of this 1000000 byte file by 0 percent.

Chi square distribution for 1000000 samples is 231.04, and randomly
would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bytes is 127.4548 (127.5 = random).
Monte Carlo value for Pi is 3.146460586 (error 0.15 percent).
Serial correlation coefficient is 0.000175 (totally uncorrelated=0.0).

Laut Doku ( http://www.frank-buss.de/tmp/ent.html ) ist das ziemlich
zufällig.
--
Frank Buß, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Michael Borgwardt
2004-07-11 18:59:08 UTC
Permalink
Post by @(none)
Es kommen hier überdurchschnittlich oft aufeinanderfolgende
Ziffernketten vor, die in der Praxis so nie auftreten. Zum Beispiel wird
hier eine 1 bis zu 10x hintereinandere geworfen.
Wie kommst Du darauf, daß das "in der Praxis so nie" auftritt? Die
Wahrscheinlichkeit dafür ist gerade mal ca. 0,1 Prozent, d.h. wenn Du
ein paar tausend Münzwürfe durchführst, sind sehr wahrscheinlich mal
irgendwo 10 gleiche Würfe hintereinander dabei.

Wahrscheinlich hast Du nur falsche Vorstellungen davon, wie wirklich
zufällige Reihen aussehen - glaubst, da dürften grundsätzlich keine
regelmäßigen Muster auftreten und wunderst Dich, wenn Du mit bloßem
Auge sofort welche findest. Das ist aber ganz normal so, denn solche
Muster entstehen sehr wohl gelegentlich durch reinen Zufall, und
das menschliche Gehirn ist außerordentlich gut darin, sie zu finden,
deswegen ist es ganz normal daß man beim Ansehen langer Zufallsreihen
solche Regelmäßigkeiten sieht.

Eventuell kannst Du ja mal java.security.SecureRandom versuchen...
Peter Gerstbach
2004-07-11 21:59:17 UTC
Permalink
Post by Michael Borgwardt
Wie kommst Du darauf, daß das "in der Praxis so nie" auftritt? Die
Wahrscheinlichkeit dafür ist gerade mal ca. 0,1 Prozent, d.h. wenn Du
ein paar tausend Münzwürfe durchführst, sind sehr wahrscheinlich mal
irgendwo 10 gleiche Würfe hintereinander dabei.
Ganz genau!
Mein Statistik-Professor hat da mal eine nette Geschichte erzählt:

Er hat mit Studenten einen Test durchgeführt. Die erste Testgruppe
schrieb 0en und 1er, die von einem Zufallszahlen-Generator kamen auf
einen Zettel auf, die andere Gruppe "erfand" selbst solche
"Zufalls-Zahlen" und schrieben sie auf einen anderen Zettel. Der
Professor wettete, dass er sofort sagen kann, welche die echten und
welche die von Menschen "erfundenen" Zufallszahlen waren.
Dies schaffte er auch, weil die Zufallszahlen von Menschen viel
regelmäßiger waren (also z.B. 01101001), als die von der Maschine, wo
deine 10 gleichen Stellen durchaus auftreten... :)
Marcus Woletz
2004-07-11 19:33:15 UTC
Permalink
Hallo Rainer,

none schrieb:
[...]
Post by @(none)
Es kommen hier überdurchschnittlich oft aufeinanderfolgende
Ziffernketten vor, die in der Praxis so nie auftreten. Zum Beispiel wird
hier eine 1 bis zu 10x hintereinandere geworfen.
Was bedeutet in der Praxis? Hast Du schon mal 1000 mal eine Münze
geworfen und das Ergebnis protokolliert. Und welche Sequenzen bitte
sollen deiner Meinung nach in der "Praxis" nicht auftreten können,
und warum nicht?
Und was ist daran so erstaunlich, wenn überhaupt nur die Zahlen 0 und 1
vorkommen können. Nur weil es nicht deiner persönlichen Voirstellung von
"Zufall" entspricht, muss es nicht unbedingt falsch sein.
Was du als Zufall erwartest ist vermutlich Chaos. Das muss allerdings
nicht so sein. Reiner Zufall eben :-)
Post by @(none)
Gibt es denn keine bessere Methoden, um Zufallszahlen zu erzeugen?
Vermutlich schon, aber wozu den Aufwand betreiben? Schildere doch mal
deine Anwendung.
Post by @(none)
Mfg,
-Rainer Hahnekamp
ciao
Marcus
Cybernd
2004-07-11 20:46:09 UTC
Permalink
Zufall oder doch nicht Zufall?
Was bedeutet denn Zufall.

Ist es bei dir zufälliger wenn immer wechsel auftreten?
Also ein 10101010101 unterscheidet sich in meinen Augen nicht von einem
0000000000 Zufälligerweise halt eine gleichlange Sequenz. (Bin jetzt zu
faul die länge zu zählen .. )

Ja Random liefert zufällige Zahlen. Ausreichend zufällig für dienen Bedarf.

Eine kleine Geschichte am Rande:

In den ersten PCs steckte ein Zufallsalgo. Dieser funktionierte
wunderbar über Monate (Jahre?) hinweg. Alles paletti bis da jemand auf
die Idee kam derartige Zufallszahlen für 3D-Simmulationen zu verwenden.

Das Resultat war folgendes:
1. Dimension, 2. Dimension, 3. Dimension, 1. Dimension ...

Es wurde also für die Berechnung regelmäßig nach dem Schema abgegriffen:

123,123,123,123,123,123

Und sieheda diese Zufallszahlen in einem 3D-Diagramm aufgezeichnet lagen
exakt in einer Ebene, also alles andere als Zufällig. (Heutige
Statistiker in diesem Bereich neigen dazu Zufallskollonnen einfach mal
ein wenig zu Falten um so auf regelmäßigkeiten zu stoßen die Ihnen den
Weweis liefern das sie doch nicht so ganz Zufällig sind)

Derartige auf leichte Beweise zur Widerlegung der Zufälligkeit sind mit
den momentan gängigen Random Algos nicht möglich. Wenn du etwas präziser
zufälliges haben willst mußt du entsprechend aufgebohrte Libs verwenden.
Die brauchen dann aber erhebliche Rechenlast pro Zufallszahl.

Wieso denkst du nun aber das ausgerechnet bei deiner simplen Aufgabe die
Zufälligkeit nicht ausreichen sollte?

Vermutlich könnte man aber wegen der 0-1 Chrakteristik nachweisen das
eventuell die 0 genauer ist als die 1 (Oder umgekehrt?), da hier
eventuelle Rundungsfehler einspielen. Und selbst wenn dies in dem Falle
so ist sage ich: Na und denn ich denke das eine Zufälligkeit von
lediglich 99% (das ist wenig) doch auch für "Münze Werfen" ausreichen
sollte.

cybi
TSK
2004-07-11 21:39:28 UTC
Permalink
Hi zusammen...

Cybernd wrote:

[Soweit ACK]
Post by Cybernd
In den ersten PCs steckte ein Zufallsalgo. Dieser funktionierte
wunderbar über Monate (Jahre?) hinweg.
Sorry, das stimmt so nicht. Es wurden immer lineare Kongruenzmethoden
verwendet, was schon schlimm war...diese waren aber
teilweise noch extrem schlecht aufgesetzt, so dass Knuth selbst
scharfe Kritik an den damals vorkommenden PRNG (Zufallsgenerator)
geübt hat.
Dieses "wunderbar" funktionieren stimmt schon deshalb nicht,
weil sich selbst im Optimalfalle nach 16 Millionen Iterationen
die Zahlen wiederholten. Das war schon seit dem 80386 keine
Monate, geschweige denn Jahre mehr.
Post by Cybernd
Alles paletti bis da jemand auf die Idee kam derartige
Zufallszahlen für 3D-Simmulationen zu verwenden.
1. Dimension, 2. Dimension, 3. Dimension, 1. Dimension ...
123,123,123,123,123,123
Und sieheda diese Zufallszahlen in einem 3D-Diagramm aufgezeichnet lagen
exakt in einer Ebene, also alles andere als Zufällig.
Marsaglia Effekt: Hier schön zu beobachten (von oben draufschauen).
http://www.physics.carleton.ca/courses/75.502/slides/java/RandomApplet/
RandomApplet.html
Post by Cybernd
Derartige auf leichte Beweise zur Widerlegung der Zufälligkeit sind mit
den momentan gängigen Random Algos nicht möglich. Wenn du etwas präziser
zufälliges haben willst mußt du entsprechend aufgebohrte Libs verwenden.
Die brauchen dann aber erhebliche Rechenlast pro Zufallszahl.
Nope. Ich stelle mal den Mersenne Twister hier zur Verfügung; dieser
verwendet nur Bitoperationen und ist deshalb extrem schnell; die
Länge der Iteration bis zur Wiederholung ist 2^19937 und weist
bis zur 623. Dimension Gleichverteilung auf.

public class MersenneTwister {
private int mti;
private int[] mt = new int[N]; // set initial seeds: N = 624 words
private byte[] seed=null; // initial seed
private boolean sucInit=false; // report if SecRandom was successful
private long iNumber=0; // number of current iteration

/* Period parameters */
private static final int N=624;
private static final int M=397;
private static final int MATRIX_A=0x9908b0df; // constant vector a
private static final int UPPER_MASK=0x80000000; // most significant
w-r bits */
private static final int LOWER_MASK=0x7fffffff; /* least significant r
bits */

/* for tempering */
private static final int TEMPERING_MASK_B=0x9d2c5680;
private static final int TEMPERING_MASK_C=0xefc60000;

private static final int mag0 = 0x0;
private static final int mag1 = MATRIX_A;
//private static final int[] mag01=new int[] {0x0, MATRIX_A};
/* mag01[x] = x * MATRIX_A for x=0,1 */

public static final int DEFAULT_SEED = 4357;
/**
* Constructs and returns a random number generator with a default seed,
which is a <b>constant</b>.
* Thus using this constructor will yield generators that always produce
exactly the same sequence.
* This method is mainly intended to ease testing and debugging.
*/
public MersenneTwister()
{
try
{
seed=new byte[4*N];
SecureRandom random=SecureRandom.getInstance("SHA1PRNG");
seed=random.generateSeed(4*N);
sucInit=fillTwister(seed);
if (!sucInit)
setSeed(DEFAULT_SEED);
}//try
catch (NoSuchAlgorithmException e)
{}
}

/**
* Constructs and returns a random number generator with a chosen
arbitrary seed,
* which is a <b>constant</b>.
* Thus using this constructor will yield generators that always produce
exactly
* the same sequence for a known seed, but with extreme variability.
* This method is mainly intended to perform strong statistical tests
@param newseed long seed stored in a byte array; the length of the
byte array must be 2496
*/
public MersenneTwister(byte[] newseed) throws IllegalArgumentException
{
if (newseed.length != (N*4))
throw new IllegalArgumentException("Wrong seed dimension:
"+Integer.toString(newseed.length));
sucInit=fillTwister(newseed);
if (!sucInit)
setSeed(DEFAULT_SEED);
}

/**
* Constructs and returns a random number generator with the given seed.
*/
public MersenneTwister(int seed) {
setSeed(seed);
}
/**
* Constructs and returns a random number generator seeded with the
given date.
*
* @param d typically <tt>new java.util.Date()</tt>
*/
public MersenneTwister(Date d) {
this((int) (d.getTime() & 0x00000000FFFFFFFF));
}
/**
* Returns a copy of the receiver; the copy will produce identical
sequences.
* After this call has returned, the copy and the receiver have equal
but separate state.
*
* @return a copy of the receiver.
*/
public Object clone() throws CloneNotSupportedException
{
MersenneTwister clone = (MersenneTwister) super.clone();
clone.mt = (int[]) this.mt.clone();
return clone;
}

public static void main(String[] args)
{
final int randtry=1000;
long walk=0;
int shortwalk=0;
int cum=0;
double border=0.0;
int number=0;

MersenneTwister twister = new MersenneTwister();
byte[] test=twister.getSeed();
for (int anz=0; anz < 1000; anz++)
{
walk=0;
cum=0;
for (int i=0; i<randtry; i++)
{
/*
shortwalk=0;
for (int j=0; j<200; j++)
{
if (twister.nextInt() < 0)
shortwalk++;
}//for
border=Math.sqrt(50*(i+1));
walk+=shortwalk-100;
*/
border=Math.sqrt((i+1)*0.25);

if (twister.nextInt() < 0)
walk++;
else
walk--;

if (((double)Math.abs(walk)) > border)
cum++;
}//for
double Percent=(new Integer(cum)).doubleValue()/randtry;
//System.out.println(walk+" "+Percent);
if (Percent > 0.317)
number++;
}//for
System.out.println((new Integer(number)).doubleValue()/1000);
}//main

/**
* Fill Mersenne Twister with arbitrary seed
*/
private boolean fillTwister(byte[] newseed)
{
if (newseed.length == (4*N))
{
for (int i=0; i<N; i++)
{
mt[i]=((int) seed[4*i] << 24) |
((int) seed[4*i+1] << 16) |
((int) seed[4*i+2] << 8)|
(int) seed[4*i+3];
}//for
return true;
}//if
else
return false;
}


/**
* Generates N words at one time.
*/
protected void nextBlock() {
/*
// ******************** OPTIMIZED **********************
// only 5-10% faster ?
int y;

int kk;
int[] cache = mt; // cached for speed
int kkM;
int limit = N-M;
for (kk=0,kkM=kk+M; kk<limit; kk++,kkM++) {
y = (cache[kk]&UPPER_MASK)|(cache[kk+1]&LOWER_MASK);
cache[kk] = cache[kkM] ^ (y >>> 1) ^ ((y & 0x1) == 0 ? mag0 : mag1);
}
limit = N-1;
for (kkM=kk+(M-N); kk<limit; kk++,kkM++) {
y = (cache[kk]&UPPER_MASK)|(cache[kk+1]&LOWER_MASK);
cache[kk] = cache[kkM] ^ (y >>> 1) ^ ((y & 0x1) == 0 ? mag0 : mag1);
}
y = (cache[N-1]&UPPER_MASK)|(cache[0]&LOWER_MASK);
cache[N-1] = cache[M-1] ^ (y >>> 1) ^ ((y & 0x1) == 0 ? mag0 : mag1);

this.mt = cache;
this.mti = 0;
*/



// ******************** UNOPTIMIZED **********************
int y;

int kk;

for (kk=0;kk<N-M;kk++) {
y = (mt[kk]&UPPER_MASK)|(mt[kk+1]&LOWER_MASK);
mt[kk] = mt[kk+M] ^ (y >>> 1) ^ ((y & 0x1) == 0 ? mag0 : mag1);
}
for (;kk<N-1;kk++) {
y = (mt[kk]&UPPER_MASK)|(mt[kk+1]&LOWER_MASK);
mt[kk] = mt[kk+(M-N)] ^ (y >>> 1) ^ ((y & 0x1) == 0 ? mag0 : mag1);
}
y = (mt[N-1]&UPPER_MASK)|(mt[0]&LOWER_MASK);
mt[N-1] = mt[M-1] ^ (y >>> 1) ^ ((y & 0x1) == 0 ? mag0 : mag1);

mti = 0;
}

/**
* Returns a 32 bit uniformly distributed random number in the closed
interval <tt>[Integer.MIN_VALUE,Integer.MAX_VALUE]</tt> (including
<tt>Integer.MIN_VALUE</tt> and <tt>Integer.MAX_VALUE</tt>).
*/
public int nextInt() {
/* Each single bit including the sign bit will be random */
if (mti == N) nextBlock(); // generate N ints at one time

int y = mt[mti++];
y ^= y >>> 11; // y ^= TEMPERING_SHIFT_U(y );
y ^= (y << 7) & TEMPERING_MASK_B; // y ^= TEMPERING_SHIFT_S(y) &
TEMPERING_MASK_B;
y ^= (y << 15) & TEMPERING_MASK_C; // y ^= TEMPERING_SHIFT_T(y) &
TEMPERING_MASK_C;
// y &= 0xffffffff; //you may delete this line if word size = 32
y ^= y >>> 18; // y ^= TEMPERING_SHIFT_L(y);

iNumber++;
return y;
}
/**
* Sets the receiver's seed.
* This method resets the receiver's entire internal state.
*/
protected void setSeed(int seed) {
mt[0] = seed & 0xffffffff;
for (int i = 1; i < N; i++) {
mt[i] = (1812433253 * (mt[i-1] ^ (mt[i-1] >> 30)) + i);
/* See Knuth TAOCP Vol2. 3rd Ed. P.106 for multiplier. */
/* In the previous versions, MSBs of the seed affect */
/* only MSBs of the array mt[]. */
/* 2002/01/09 modified by Makoto Matsumoto */
mt[i] &= 0xffffffff;
/* for >32 bit machines */
this.seed[4*i] =(byte) ((mt[i] >> 24) & 255);
this.seed[4*(i+1)] =(byte) ((mt[i] >> 16) & 255);
this.seed[4*(i+2)] =(byte) ((mt[i] >> 8) & 255);
this.seed[4*(i+3)] =(byte) (mt[i] & 255);
}
iNumber=0;
//System.out.println("init done");
mti = N;

/*
old version was:
for (int i = 0; i < N; i++) {
mt[i] = seed & 0xffff0000;
seed = 69069 * seed + 1;
mt[i] |= (seed & 0xffff0000) >>> 16;
seed = 69069 * seed + 1;
}
//System.out.println("init done");
mti = N;
*/
}

/**
* Get the seed
*/
public byte[] getSeed()
{ return seed; }
}

Grüße
Thorsten
--
Bitte Reply-To: unverändert verwenden; die Adresse ist gültig.
Carl Rosenberger
2004-07-11 22:19:38 UTC
Permalink
Post by TSK
Ich stelle mal den Mersenne Twister hier zur Verfügung;
Danke.

Wie sieht es mit dem Copyright aus?
--
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
TSK
2004-07-11 22:35:26 UTC
Permalink
Post by Carl Rosenberger
Post by TSK
Ich stelle mal den Mersenne Twister hier zur Verfügung;
Danke.
Wie sieht es mit dem Copyright aus?
Das Beispiel stammt aus der Colt-Distribution von
Wolfgang Hoschek. Makoto Matsumoto and Takuji Nishimura,
die Erfinder des Codes, haben seiner uneingeschränkten
Verwendung ausdrücklich zugestimmt:

http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/MT2002/elicense.html

Grüße
Thorsten
--
Bitte Reply-To: unverändert verwenden; die Adresse ist gültig.
Cybernd
2004-07-12 08:46:18 UTC
Permalink
Post by TSK
teilweise noch extrem schlecht aufgesetzt, so dass Knuth selbst
scharfe Kritik an den damals vorkommenden PRNG (Zufallsgenerator)
geübt hat.
Und wie lange war der Zeitraum zwischen dem ersten Einsatzes dieses Alos
und Knuts Kritik? Etwa doch länger als ein Monat?
Post by TSK
Dieses "wunderbar" funktionieren stimmt schon deshalb nicht,
weil sich selbst im Optimalfalle nach 16 Millionen Iterationen
die Zahlen wiederholten. Das war schon seit dem 80386 keine
Monate, geschweige denn Jahre mehr.
Wunderbar funktionieren ist dehnbar. Wie lange waren alle damit
zufrieden das Sie auf einem CGA spielen konnten? Heutzutage sind alle
mit >= XGA verwöhnt und würden derartige Spiele nicht mehr anrühren.
Damals waren dennoch alle Happy mit diesen kleinen Games.

Für die meisten damaligen Applikationen war diese Art der
Zufallszahlengewinnung durchaus "ausreichend".

Der von mir geschilderte Fall führte eben dazu das Sie entdeckten das
selbst die Zahlen in dieser Zahlenmenge der 16 Mio Iterationen nunmal
alles andere als Zufällig waren, was man zuvor eben auch noch nicht wußte.
Post by TSK
http://www.physics.carleton.ca/courses/75.502/slides/java/RandomApplet/
RandomApplet.html
Thx sehr anschaulich. Ich bekam das damals als Mathcad (Oder wars
Mathlab?) Simmulation präsentiert. (Also leider nur ein einzelner
statischer Screenshot)
Post by TSK
Nope. Ich stelle mal den Mersenne Twister hier zur Verfügung; dieser
verwendet nur Bitoperationen und ist deshalb extrem schnell; die
Länge der Iteration bis zur Wiederholung ist 2^19937 und weist
bis zur 623. Dimension Gleichverteilung auf.
Theoretisch müsste ich jetzt diesen Twister mit der
Defaultimplementierung der Random vergleichen ;o) Ob hier unterschiede
in der Performance erkennbar sind?

So oder so sehe ich hier einiges an "Berechnungen" die aus meiner naiven
Sichtweise einen Mehraufwand gegenüber den simplesten Berechnungen
bieten. Ja mag sein das dieser Mehraufwand vernachlässigbar ist, aber
dennoch ist er nunmal "vorhanden". Und ja auch schön das du mit dem
Twister eine Implementierung vorweisen kannst die recht wenig Last
erzeugt. Es gibt nunmal aber auch andere Implementierungen die weitaus
mehr Zyklen pro Zahl benötigen.
Post by TSK
2^19937
Randbemerkung: Korrekterweise wärens 2^19937 - 1
(Ich weiß, ist korrintenkackerei, bin nur gerade eben irgendwo
drübergestolpert)

Nun noch zwei Aussagen zum Twister:
(http://www.matheboard.de/lexikon/index.php/Mersenne_Twister)
Post by TSK
Im Gegensatz zu anderen Algorithmen ist der Mersenne Twister in
seiner > Reinform nicht für kryptographische Anwendungen geeignet.
Post by TSK
Er ist schneller als jeder andere bekannte (hinreichend gute)
Algorithmus
Ergibt in meinen Augen ein eindeutiges:
Wer höherwertige Alorithmen benötigt muß damit leben das diese mehr
Prozessorzyklen benötigen. Exakt die Aussage die ich auch in der Mail
vorhin bereits zu sagen versuchte.

Wobei nach wie vor der Defaultalgo für den Fall "Münzwurf" mehr als
ausreichend sein sollte.

cybi
TSK
2004-07-12 20:41:34 UTC
Permalink
Post by Cybernd
Post by TSK
teilweise noch extrem schlecht aufgesetzt, so dass Knuth selbst
scharfe Kritik an den damals vorkommenden PRNG (Zufallsgenerator)
geübt hat.
Und wie lange war der Zeitraum zwischen dem ersten Einsatzes dieses Alos
und Knuts Kritik? Etwa doch länger als ein Monat?
Die erste Auflage von "The Art of Comp. Progr., Seminum. Algorithms"
stammt von 1969; ich habe die Kritik in der 1981er Ausgabe gelesen,
bin mir aber ziemlich sicher, dass sie schon in den früheren
Auflage erwähnt wurde.
Den fraglichen Generator RANDU gab es erst nur in Assembler während
den frühen 60ern, die FORTRAN-Version war erst 1970 (!) erhältlich.

http://crypto.mat.sbg.ac.at/results/karl/server/node4.html#randu

Da Du von PCs gesprochen hast (was war der früheste PC ?)...
Post by Cybernd
Post by TSK
Dieses "wunderbar" funktionieren stimmt schon deshalb nicht,
weil sich selbst im Optimalfalle nach 16 Millionen Iterationen
die Zahlen wiederholten. Das war schon seit dem 80386 keine
Monate, geschweige denn Jahre mehr.
Wunderbar funktionieren ist dehnbar. Wie lange waren alle damit
zufrieden das Sie auf einem CGA spielen konnten? Heutzutage sind alle
mit >= XGA verwöhnt und würden derartige Spiele nicht mehr anrühren.
Damals waren dennoch alle Happy mit diesen kleinen Games.
Für die meisten damaligen Applikationen war diese Art der
Zufallszahlengewinnung durchaus "ausreichend".
PCs wurden zu dem Zeitpunkt, als die Kritik schon bekannt war,
hauptsächlich für Geschäfte und Wissenschaft verwendet. Leider
hat SPSS den RANDU implementiert, so dass viele statistische
Berechnungen damit angestellt wurden.
Post by Cybernd
Post by TSK
Nope. Ich stelle mal den Mersenne Twister hier zur Verfügung; dieser
verwendet nur Bitoperationen und ist deshalb extrem schnell; die
Länge der Iteration bis zur Wiederholung ist 2^19937 und weist
bis zur 623. Dimension Gleichverteilung auf.
Theoretisch müsste ich jetzt diesen Twister mit der
Defaultimplementierung der Random vergleichen ;o) Ob hier unterschiede
in der Performance erkennbar sind?
Der Twister ist (P4 2GHz,1.4.2) gegenüber Random.nextInt() um den
Faktor 10-20 *schneller*.
Post by Cybernd
So oder so sehe ich hier einiges an "Berechnungen" die aus meiner naiven
Sichtweise einen Mehraufwand gegenüber den simplesten Berechnungen
bieten. Ja mag sein das dieser Mehraufwand vernachlässigbar ist, aber
dennoch ist er nunmal "vorhanden".
Soso.

Grüße
Thorsten
--
Bitte Reply-To: unverändert verwenden; die Adresse ist gültig.
Daniel Urban
2004-07-11 21:27:38 UTC
Permalink
Post by @(none)
ich wollte mit folgendem Code einen Münzwurf simulieren, allerdings
java.util.Random lottery = new java.util.Random();
for(int i = 0; i <= 1000; i++) {
System.out.print(lottery.nextInt(2));
}
Es kommen hier überdurchschnittlich oft aufeinanderfolgende
Ziffernketten vor, die in der Praxis so nie auftreten. Zum Beispiel wird
hier eine 1 bis zu 10x hintereinandere geworfen.
Gibt es denn keine bessere Methoden, um Zufallszahlen zu erzeugen?
Du hast glaube ich ein falsches Verständis von Zufall, aber lassen wir das
mal. ;-) Natürlich handelt es sich nur um einen Pseudozufallsgenerator, denn
echten Zufall kann man im Computer schwer herstellen.

Die Güte so eines Pseudozufallsgenerators hängt davon ab, mit wieviel
Aufwand man die Zahlenfolge (oder Teile davon) vorhersagen kann. Der
Alogorithmus ist bekannt, nur der Kern (Startwert) ist normalerweise nicht
bekannt. Also muß der Algorithmus so sein, daß man an der bisherigen
Zahlenfolge den Kern nicht ableiten kann und/oder daß man aus der
Zahlenfolge nicht die nächsten Zahl vorhersagen kann. Dazu gehört aber auch,
daß man für die nächste Zahl keinen Wert angeben kann, der mit erhöhter
Wahrscheinlichkeit kommt.

Da das letztendlich eine Frage des Aufwands ist, muß man fragen, was Du mit
den Zahlen machen willst. Für viele Anwendungsfälle wird der Algorithmus
schon reichen.

An dieser Stelle kann ich mal wieder Bruce Schneier "Angewandte
Kryptographie" emfpehlen.

Gruß,

Daniel
Marian Aldenhövel
2004-07-11 21:22:34 UTC
Permalink
Ho,
Post by @(none)
Gibt es denn keine bessere Methoden, um Zufallszahlen zu erzeugen?
Du könntest eine Münze werfen.

Aber wahrscheinlich wäre das viel weniger zufällig als
java.util.Random weil Deine Münze nicht ideal ist, und Du sie
nicht ordentlich werfen würdest.

Der Unterschied zwischen Pseudo-Zufall wie ihn dieser Generator erzeugt,
und echtem Zufall ist für ein Programm wie Deines völlig irrelevant.
Der Generator ist gut, prüfe Deine Vorstellungen von zufälligen Folgen.
Post by @(none)
Zum Beispiel wird hier eine 1 bis zu 10x hintereinandere geworfen.
Bei echt zufälligen Folgen wäre _garantiert_, daß eine solche Folge
auftritt wenn Du nur lange genug wartest. Sogar hundert Einsen müssten
irgendwann erscheinen. Ja selbst 10^10 Einsen.

Von java.util.Random darfst Du dieses zwar nicht erwarten, aber
rechne doch mal aus, wie wahrscheinlich es bei echtem reinem und
idealem Zufall wäre, 10 mal hintereinander Kopf oder Zahl zu
bekommen.

Menschen sind notorisch schlecht beim Schätzen von
Wahrscheinlichkeiten. Du bist ein weiterer Beweis für diese Tatsache
:-).

Ciao, MM
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"Wie trennt man drei Schlampen von zwei Säufern? Cockpittüre zu!"
Michael Borgwardt
2004-07-11 22:31:16 UTC
Permalink
Post by Marian Aldenhövel
Bei echt zufälligen Folgen wäre _garantiert_, daß eine solche Folge
auftritt wenn Du nur lange genug wartest. Sogar hundert Einsen müssten
irgendwann erscheinen. Ja selbst 10^10 Einsen.
Nein, garantiert wäre nichts davon. Es würde lediglich die Wahrscheinlichkeit
dafür mit steigender Länge der Reihe gegen 1 konvergieren.
Marian Aldenhövel
2004-07-12 00:00:39 UTC
Permalink
Hi,
Post by Michael Borgwardt
Nein, garantiert wäre nichts davon. Es würde lediglich die
Wahrscheinlichkeit dafür mit steigender Länge der Reihe gegen
1 konvergieren.
Es ist spät. Aber bedeutet das nicht dasselbe?

Ciao, MM
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"Wie trennt man drei Schlampen von zwei Säufern? Cockpittüre zu!"
Jonathan Heinen
2004-07-12 00:09:08 UTC
Permalink
Hallo alle Haarspalter =)

"Marian Aldenh�vel" <***@mba-software.de> schrieb im Newsbeitrag news:***@uni-berlin.de...

[...]
Post by Marian Aldenhövel
Post by Michael Borgwardt
Wahrscheinlichkeit dafür mit steigender Länge der Reihe gegen
1 konvergieren.
Es ist spät. Aber bedeutet das nicht dasselbe?
Praktisch ja theoretisch nein =)

Es heißt nur das die Wahrscheinlichkeit mit wachsender länge immer größer
wird und immer näher an 100% heran kommt aber ne Garantie ist es nicht!...

Wir müssen ja schließlich alle Möglichkeiten betrachten! Also auch die wo
wir eine endlose folge von 1 mal Kopf 1 mal Zahl ... haben! Theoretisch kann
auch das passieren ist aber sehr unwahrscheinlich (strebt gegen 0 =) )
genauso wie auch die wahrscheinlichkeit, dass irgendeine andere letzendlich
periodische reihenfolge auftritt! (oder auch nicht periodisch anders
vorgegeben)

Jonathan
Loading...