Zufallsgenerator mit Gewichtung (aber mit sehr großen Datenmengen)

[Jumpy]

Wenn du Random(10) sagst, können die Zahlen 0..9 rauskommen.

[Perlsau]

Zitat:

Zitat von Jumpy (Beitrag 1262706)

Wenn du Random(10) sagst, können die Zahlen 0..9 rauskommen.

Falsch! Da kommen die Zahlen 0..10 heraus, wie ich oben bereits dargestellt habe. Es ist eher so: wenn du Werte von 1 bis 10 haben willst, nimmst du Random(9) und zählst 1 dazu.

[Uwe Raabe]

Zitat:

Zitat von Perlsau (Beitrag 1262708)

Zitat:

Zitat von Jumpy (Beitrag 1262706)

Wenn du Random(10) sagst, können die Zahlen 0..9 rauskommen.

Falsch! Da kommen die Zahlen 0..10 heraus, wie ich oben bereits dargestellt habe. Es ist eher so: wenn du Werte von 1 bis 10 haben willst, nimmst du Random(9) und zählst 1 dazu.

Perlsau - Sie reden wirr!

[himitsu]

Zitat:

Hier mal mein Code der zwar funktioniert, aber nur wenn ich die Summen um den Faktor 100 dividiere.

Das klingt ja fast so, als wenn du da irgendwo z.B. einen Integerüberlauf bekommst, wenn es bei großen Zahlen nicht mehr geht. :gruebel:
[edit] Oder eben ein Speicherproblem: Arbeitspeicher ist voller Strings und auch die StringList selbst besitzt eine maximale Anzahl an möglichen Einträgen, und zwar sind das ganz genau

Delphi-Quellcode:

Max(NativeInt) div (SizeOf(Pointer) * 2)

in Win32 sind das maximal 268.435.455 Einträge, wobei es effektiv (auf Grund des Arbeitsspeichers) vielleicht nur maximal 32.768.000 Zeilen sind (eher weniger, da ich davon ausgegangen bin, daß ein freier 250MB-Bereich zusammenhängend existiert und jede Zeile einen Leerstring enthält :stupid:).



Habt ihr über 2 Milliarden € (2.147.483.647) als Gesamt-Einlagen?

Wenn nicht, dann sollte es keinen Überlauf geben.
OK, wenn man die Extremwerte nimmt, dann schon (150000*1000000 = 150.000.000.000), aber in der durchschnittlichen Summe doch wohl nicht.

Annahme: pro 1€ gibt es eine Gewinnchance
- Maximum Bereich des Zufallswertes errechnen = Einlagen aller Leute (eventuell jeweils auf ganze € abgerundet)
- Zufallswert bestimmen = Random(Gesamteinlage)
- dann wieder die Kunden durchgehen und solange von dem Zusfallswert die jeweilige Einlage abziehen, bis der Wert unter 0 sinkt ... das ist dann der Gewinner.

[edit]
Also im Prinzip so, wie es schon genannt wurde.

Vom Vorgehen her ist es wie dein Code, nur das die "Liste" nicht in Real, sondern nur virtuell erstellt wird und es somit nahezu keinen Speicherverbrauch gibt.
Denn, wenn man diese Liste nicht auch noch vermischt, dann lässt sich mathematisch berechnen welche Person sich in jeder Zeile befindet.

[Perlsau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262711)

Perlsau - Sie reden wirr!

In der Tat! Und zwar äußerst :stupid:

[Bambuti2000]

Also,

nochmals vielen Dank für eure Beiträge.
Die +1 im Random hab ich jetzt auch verstanden.

Ich denke so können wir demnächst bestimmt ein paar iPads an unsere Kunden verlosen.

@himitsu
Du liegst mit all deinen Vermutungen richtig (bis auf die Gesamt-Einlagen).
Und somit hab ich es auch nach Dejan Vu's Erläuterung umgesetzt.

Danke nochmals. :thumb:

[himitsu]

Ich wollte schon fragen, ob wir jetzt auch einen Dankeschön-Einlageneuro gesponsort bekommen, aber dann müssen wir uns auch noch 'nen Mac kaufen, weil sich das iPad ohne ja nicht nutzen lässt (für die Entwicklung), also dann besser doch nicht. :stupid:

Wobei: Ist das so eigentlich "gerecht"?
Gut, wer mehr bezahlt, hat höhere Chancen, aber sind das dann nicht die Reichen, welche eh schon 5 iPads als eBookreader auf'm Klo liegen haben?

[Jumpy]

Wo du doch von Klo redest, so ist es doch eine bekannte Tatsache das Sch... auf den dicksten Haufen fällt. :-D

[Dejan Vu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262688)

...Inwieweit unterscheidet sich das von meiner Lösung (Post #2)?

Nur in der Implementierung.[/QUOTE] Lass ich gelten, obwohl 'Addieren bis Erreichen oder Überschreiten der Zahl' äquivalent mit 'abziehen, solange das Ergebnis >=0' ist. Meine Version benötigt eine Variable weniger, was wirklich extrem wichtig ist. ;-)