Verteilung von runs

Neue Frage »

Dopap Auf diesen Beitrag antworten »
Verteilung von runs
Wenn man aus einer dichotomen Grundmenge zufällig w>0 weiße Kugeln und s>0 schwarze Kugeln
und damit ein Tupel der Länge zieht,
sind einige runs dabei, wobei 1 run = eine Folge gleichartiger Kugeln ist.

Beispiel: hat r=6 runs

Die Wahrscheinlichkeit, dass die Zufallsgröße R= Anzahl der runs einen gewissen Wert annimmt ist bei
  • r gerade und k=1/2r

  • r ungerade und k=1/2(r+1)-1


Wenn die Annahme einer zufälligen Entnahme bestehen soll, dann sollte es nicht zu wenige runs
aber auch nicht zu viele davon geben.
Um die Quantile für zu bestimmen, muss die Verteilungsfunktion(?) von ausgewertet werden.

was aber unklar ist. Zudem teminiert im konkreten Fall dieses bei ca 0.8

2 berechnete Beispiele :


Irgendwo müsste ein logischer oder ein Programm-Fehler stecken. verwirrt
HAL 9000 Auf diesen Beitrag antworten »

Zitat:
Original von Dopap
was aber unklar ist.

Bei dem als oberen Summenindex meinst du aber nicht wie oben , oder? Denn es kann ja gar nicht mehr als runs geben (und genau ja auch nur bei ), insofern ist bei deiner Schreibweise im Fall immer

Ich nehme daher an, du redest von , sinnvoll in dieser Darstellung von , oder genauer noch .

Zitat:
Original von Dopap
Zudem teminiert im konkreten Fall dieses bei ca 0.8

Soll das heißen, du bekommst für irgendeine Konstellation ? Das kann sich dann tatsächlich nur um einen Rechenfehler handeln. An den Formeln oben liegt es jedenfalls nicht, denn die sind in Ordnung.
Dopap Auf diesen Beitrag antworten »

Zitat:

was aber unklar ist.

Zitat:
Original von HAL 9000
Bei dem als oberen Summenindex meinst du aber nicht wie oben , oder?


doch Ups leider verzählt, aber mit deinem

sind jegliche Unklarheiten beseitigt.

große Stichproben waren und sind nicht das Problem, da wegen



die Normalverteilung als Näherung zur Verfügung steht.
HAL 9000 Auf diesen Beitrag antworten »

Das beantwortet jetzt nicht meine Nachfrage

Zitat:
Original von HAL 9000
Zitat:
Original von Dopap
Zudem teminiert im konkreten Fall dieses bei ca 0.8

Soll das heißen, du bekommst für irgendeine Konstellation ?

verwirrt


P.S.: Der Nachweis der Formeln






ist übrigens eine nette Übungsaufgabe. smile
Dopap Auf diesen Beitrag antworten »

Zitat:
Original von HAL 9000
Soll das heißen, du bekommst für irgendeine Konstellation ?


leiderJa
HAL 9000 Auf diesen Beitrag antworten »

Hmm, so triviale Sachen wie Bereichsüberlauf (bei den gängigen Integertypen schnell erreicht, aber auch die Floating-Point-Formate "halten" nicht ewig) hast du aber ausgeschlossen?
 
 
Dopap Auf diesen Beitrag antworten »

floating point geht bis 10^(+- 500) und over/under) flow - flag ist true.

COMB(n,k) rechnet nicht mit Fakultäten.

Aber nach umständlichen debuggen ist einer jener Fieslinge gefunden:
Irgendwo ein + statt einem * aber so, dass es erst einmal nicht auffällt unglücklich

immerhin ist jetzt erst bei über 0.99 Schluß.
Probleme macht noch der definitiv Letzte= P11,5,6) aber der ist eben der Rest Augenzwinkern

Nein, geht gegen die Ehre! da schau ich dann noch danach.

Und nicht so wie ich schon sehen musste :

IF i==R THEN return (1-sum) END Augenzwinkern

edit: i==n nicht R
Dopap Auf diesen Beitrag antworten »

wenn dann läuft eine Summe von 2 bis maximal
richtig?

Das Problem ist jetzt die ungerade Auswertung bei z.B.
das k ist dann

gleich zu Beginn liefert das Rote einen COMB error da



Ein w-s Vertauschen bringt nix dann kommt der error eben vom letzten COMB in Zähler.
HAL 9000 Auf diesen Beitrag antworten »

Dann ist das eine lausige Implementierung von COMB. Es ist ja

für alle ,

damit folgt für alle natürlichen Zahlen mit .
Dopap Auf diesen Beitrag antworten »

genau ! und deshalb hatte ich mal mein persönliches COMB2 geschrieben,
das u.a. noch größere n,k zulässt aber natürlich langsam ist. ( Interpreter !)

Ende gut alles gut, mit COMB2 jetzt ist smile
Neue Frage »
Antworten »



Verwandte Themen

Die Beliebtesten »
Die Größten »
Die Neuesten »