Roulette-Strategie-Simulator

[lbccaleb]

Also siehe mein Edit:

Wenn das nicht zutrifft:

while ((aManque - aPasse) < 5) and ((aPasse - aManque) < 5) do


also aManque - aPasse und aPasse - aManque größer als 5 sind, wird i nicht mehr abgearbeitet und die Funktion ruft sich immer wieder selbst auf.

[Der Siedler]

Wenn die Bedingung nicht eintritt, ruft die Prozedur "Stueckgewinn" immer wieder "Wurf" auf, nicht sich selbst. Und das sollte doch kein Problem sein, auch, wenn das von mir aus 100.000 Mal passieren muss, bis die Bedingung eintritt. Mein Problem ist, dass ich genau die Zahl haben will, nachdem der gesuchte Fall endlich eintritt, um einen Überblick zu bekommen. Wenn das Programm aber bei den wirklich großen Zahlen abbricht, nützt mir das de facto gar nichts. Dass es viele Fälle gibt, wo das recht zeitnah eintritt, ist mir klar, aber ich will eben auch die Fälle erfassen, wo es eine halbe Ewigkeit oder länger dauert.

@DeddyH: Danke! Werde ich mir mal ansehen und ausprobieren.

[baumina]

Noch 2 kleine Tipps:

1. Schreibe im btStartClick vor Stueckgewinn ein Screen.Cursor := crHourGlass und nach Stueckgewinn ein Screen.Cursor := crDefault. Dadurch hast du eine Sanduhr während er läuft.

2. Schreibe am Ende innerhalb aller while-Schleifen ein Application.ProcessMessages. Dadurch legst du nicht alles lahm und der "weisse Bildschirm" ist damit auch nimmer.

[p80286]

Delphi-Quellcode:

procedure TfMasseEgale.Stueckgewinn;
begin
  if i < strtoint(edAnzahl.Text) then begin
    while ((aManque - aPasse) < 5) and ((aPasse - aManque) < 5) do begin
      Wurf('Keine Wette');
    end;

    if aManque - aPasse = 5 then Passespiel
    else Manquespiel;
    
    Stueckgewinn;

  end;
  lbGewinn.Caption := floattostr(aGewinn) + ' Gewinn, Rückhalt: ' + floattostr(-aMinus);
  edAnzahl.Text := inttostr(i);
end;

Wenn das kein Selbstaufruf ist...
Und wo kommt deses i her. Ich finde die Verdammung der globalen Variablen oft zu ideologisch, in diesem Fall kann ich nur sagen "recht so". Zumindestens beim debuggen sind sie alles andere als hilfreich.

Gruß
K-H

[Der Siedler]

@p80286: Bei allem Respekt, ich glaube nicht, dass das Problem in diesem Programm am Selbstaufruf von "Stueckgewinn" liegt. Wenn man sich das ganze mal näher ansieht, wird man merken, dass der Fehler da nicht liegen kann. Der Aufruf passiert ja nur, wenn i unter der festgelegten Grenze liegt, und die habe ich in meinen Testläufen bisher immer auf 1 gesetzt. Trotzdem tritt der Fehler auf, obwohl der Selbstaufruf de facto nicht mehr auftreten kann! Das kann man also vorerst übergehen.

@baumina: Danke

[Jumpy]

Ist jetzt nicht der Fehler/das Problem, aber wäre es nicht einfacher in Wurf, aManque und aPasse jeweils auf 0 zu setzen wenn das Gegenteilige Ereignis (und Zero?) eintritt? Dann muss man nicht mit dieser komplizierten while Bedingung und dem minus 5 usw. arbeiten:

Ausserdem könnte man eine variable für die maximale Anzahl an durchgängen machen und dann in ButtonClick einmalig:

imax:=strtoint(edAnzahl.Text);

und in Stückgewinn dann
if i < imax ...


Ausserdem ruft sich Stückgewinn ja immer wieder selber auf und wenn dann irgendwann mal diese Aufrufkette das Ende erreicht, schreiben alle diese Funktionen nacheinander Rückwärts 10.000 mal das selbe in die Labels, das ist glaub ich auch nicht was gewollt ist.

Das heißt diese Ausgabezeilen am Ende von Stückgewinn besser an das Ende von ButtonClick.

[Der Siedler]

Hi Jumpy, das mit dem Schreiben in die Labels war mir auch schon aufgefallen, fand ich aber jetzt nicht soo schlimm. Du hast aber Recht, so kann man es viel eleganter lösen.

if i < imax geht dagegen nicht. Es soll gerade so sein, dass Stueckgewinn noch aufgerufen wird, wenn i noch nicht erreicht ist. Dann soll das aber auf jeden Fall zu Ende geführt werden. Auch, wenn es dafür nicht i Durchgänge, sondern vielleicht sogar 2i oder noch mehr braucht. Aber wenn man nur edAnzahl.Text durch imax ersetzt, wird es höchstens übersichtlicher, aber ändern tut das doch nichts, oder?

Auch deinen ersten Vorschlag habe ich nicht ganz verstanden. Es geht ja nicht darum, fünf mal Manque oder Passe in einer Reihe zu haben, sondern insegsamt fünf mal mehr Manque als Passe oder umgekehrt. Mir ist da keiner andere Lösung eingefallen, als beide zu zählen und dann eben die Differenz zu ermitteln.

Jedenfalls Danke für deine Mühen!

[Jumpy]

Ich kannte diese Strategie nicht und war davon ausgegangen, dass dabei immer dann "das eine" gespielt wird, wenn x mal (oder mehr) "das andere" hintereinander gefallen ist. Deswegen der nicht hilfreiche Vorchlag 1.

Das mit dem imax war tatsächlich nur der übersichtlichkeit halber. Es wäre halt immer der aufruf strtoint(edAnzahl.Text) durch eine Variable ersetzt worden. edAnzahl.Text ändert sich ja nach dem ButtonClick erstmal nicht mehr, weswegen das ruhig in einer Variablen abgelegt werden könnte.

Vielleicht noch eine Idee: Debugging stell ich mir auch etwas schwierig vor, da ja evtl. einige hundert(?) Runden ins Land gehen können, bevor man was sieht. Vielleicht könntets du in jeder Runde die Inhalte deiner Variablen z.B. in eine Stringlist "loggen" und diese alle x-hundert Runden abspeichern und dir mal angucken, wie sich die Variablen verhalten?

Vielleicht ist ja der Zufallsgenerator so gleichverteilt(?), das nie eine Variante 5 Vorsprung vor der anderen hat...

[Volker Z.]

Hallo,

ich vermute mal, dass Dein Problem mit Endlosschleifen hier liegt:

Delphi-Quellcode:

procedure TfMasseEgale.Manquespiel;
var 
  aGewinnziel : real;
begin
  aGewinnziel := aGewinn + 1;
  while aGewinn < aGewinnziel do
    Wurf('Manque')
end;

bzw.

Delphi-Quellcode:

procedure TfMasseEgale.Passespiel;
var 
  aGewinnziel : real;
begin
  aGewinnziel := aGewinn + 1;
  while aGewinn < aGewinnziel do
    Wurf('Passe')
end;

Annahme: Der Aufruf von Stueckgewinn erfolgt über btStartClick und die Bedingung |aManque - aPasse| < 5 ist irgendwann erfüllt. Die while Schleife wird verlassen und es erfolgt der Aufruf von Passespiel (oder Manquespiel was aufs selbe rausläuft). Dann ist aGewinn zunächst 0. Nun wird Wurf ('Passe') mindestens einmal aufgerufen. Ist Dir das Glück nicht hold, kommen häufiger die Zahlen 0..18 und aus Deinem Gewinn wird bald ein ordentlicher Verlust (und aGewinn < aGewinnziel bleibt erfüllt). Selbst wenn gelegentlich die Kugel im Bereich 19..36 zu liegen kommt, erhöhst Du den Gewinn immer nur um Eins (pWette = Passe damit ist pWette <> 'Keine Wette' immer erfüllt).
Ändere mal Deine Wurf Methode ab:

Delphi-Quellcode:

procedure TfMasseEgale.Wurf (pWette : string);
begin
  a := Random(37);
  case a of
    0      : begin
               aZero := aZero + 1;
               if pWette <> 'Keine Wette'
                 then aGewinn := aGewinn - 0.5;
             end;
    1..18  : begin
               aManque := aManque + 1;
               if pWette = 'Manque'
                 then aGewinn := aGewinn + 2
               else
                 if pWette <> 'Keine Wette'
                   then aGewinn := aGewinn - 1
             end;
    19..36 : begin
               aPasse := aPasse + 1;
               if pWette = 'Passe'
                 then aGewinn := aGewinn + 2
               else
                 if pWette <> 'Keine Wette'
                   then aGewinn := aGewinn - 1
             end;
  end;
  i := i + 1;
  if aGewinn < aMinus
    then aMinus := aGewinn;
end;

und nutze aMinus als zusätzliche Abbruchbedingung, wenn eine bestimmte Schranke unterschritten wird.

Gruß

[Der Siedler]

@Volker: Das Problem dabei ist, dass dafür nicht eine bestimmte Schranke von aMinus unterschritten werden muss. Es kann sich auch konstant bei 10 Abweichung einpendeln und nie auf 4 fallen. Somit würde das ganze auch gefühlt ewig laufen, obwohl aMinus gar nicht sonderlich unüberschaubar wird.

@Jumpy: Doch, diese Ungleichverteilung kommt vor. Nur kommt es eben manchmal auch vor, dass das Ganze sich nicht wieder auf ein normales Niveau einpendelt. Es wird aber durchaus das Manque-/Passespiel aufgerufen, das haben zahlreiche Testläufe gezeigt.

Trotzdem Danke für eure Ideen! Das, was Volker da als Annahme schreibt, wird wohl wirklich das Problem sein. Nur frage ich mich, wieso... Gibt es in Delphi irgendeine bekannte Grenze von Nicht-Zähl-Schleifen, sprich in puncto Durchläufe? Ich kann mir keine andere Möglichkeit vorstellen. Aber wie könnte man das umgehen? Vielleicht eine while-Schleife nur 1000 Mal laufen lassen und dann wiederholen. Aber das wäre lächerlich und alles andere als elegant.