Mit welchen Datentypen und Strukturierung am Besten dutzende Baccaratspiele Shcritt für Schritt durchsimulieren?

[berndoa]

Hallo,
ich würde mir gerne zum Spiel "Baccarat" durch im Prinzip Ausprobieren aller Möglichkeiten gerne den Erwartungswert bzw. die Wahrscheinlichkeiten herausfinden.

zu Baccarat:
Nach vorgegebenen Regeln ziehen 2 Parteien Karte und hinterher wird nach ebenso festen Regeln festgelegt ob A gewinnt, B gewinnt oder Gleichstand.
Zum Endergebnis bestimmen wird jeder der Karten ein Zahlenwert zugeordnet und modulo 10 die Kartenwerte zusammengezhält.

Hat A bspw. die Karten "4,7,Bube", dann entspricht die 4 dem wert 4, die 7 dem wert 7 und Bube hat einen Wert von 0.
die modulo 10 addiert ergibt also 1 (weil 4+7+0=11 und das modulo 10 ergibt 1).
analog wird für B ein Wert seiner Hand bestimmt.
Und verglichen.

Nun gibt es ja nur eine endliche (wenngleich auch ziemlich große) Anzahl an Möglichkeiten wie so ein Spiel verlaufen kann.
Und hängt einfahc nur davon ab, welche Karte zufallsbedingt gezogen wird.

Ich will also jedes einzelne mögliche Spiel durchspielen und rausfinden wer gewinnt.
zu jedem Spiel lässt sich mit Stochastik die Eintrittswahrscheinlichkeit bestimmen.

Durch addieren aller Wahrscheinlichkeiten von spielen, in denen A gewinnt, findet man eben die Gewinnwahrshceinlichkeit für A raus.
Analog die für B sowie die für Gleichstand.


Nur bin ich mir unsicher wie ich datentyptechnisch und organisatorsich am Besten so ein Spiel simuliere.

Weil ich fange an mit der "Spielsituation" wo A und B keine Karte haben, dann passiert eine Aktion wie "A zieht Karte mit Wert 5" (was natürlich gemäß der Regeln des Spiels) erfolgt, dann haben wir entsprechend eine neue Spielsituation wo A die Karten [5] hat und B [].
Dann passiert die gemäß Regeln nachfolgende Aktion, Spielsituation wird geupdated, etc.
Bis wir irgendwann in der Spielsitation angkeommen sind, wo Alles "zu Ende gespielt ist" und der Gewinner feststeht.

Ich gehe also jede SPielsituation Schritt für Schritt durch von Anfang bis Ende.

Und das für alle möglichen Spiele, in einem Spiel zieht A ein As, im Anderen spiel zieht er ne 3 als erste Karte.
Zur Wahrscheinlichkeitsbestimmung muss natürlich getrackt werden welche Karten gezogen wurden.


im primitivsten Fall hätte ich die sich mit jedem Schritt verändernde Spielsituation simpel als mehrfach Array aufgefasst, wo bspw. das erste Unterarray die in der aktuellen Situation vorliegenden karten von A beschreibt, das 2. unterarray die von B, etc.

Also sowas wie {{As,5}{7}} die Situation beschreibt wo A erst ein As und dann eine 5 zog und B eine 7 hat.
Aber vermutlich ist das , wie es einer so shcön ausdrückt, mal wieder "ein Griff ins Klo", wie Alles was nicht sauumständliche Datentypen, Enums und Whatnots benutzt um zu zeigen was für ein geiler Fcker und Nerd man ist.

Daher dachte ich, ich frage hier mal die Überprofis wie ihr so hochprofessionell sowas programmieren würdet.
Ein "Frontend" sozusagen ist übrigens nicht nötig, ich will das nicht mit einer Gui, buttons und Co. anzeigen lassen, ich will es nur theoretisch im hintergrund ruchrechnen lassen. Muss nciht groß fanvy dargestellt und visualisiert werden, es geht mir um den harten Mathekern.

 

[White_Fox]

Ich würde an deiner Stelle erstmal überschlagen, wie hoch der Rechenaufwand wird.

Ich kenne das Spiel nicht, habe aber so den Verdacht daß du deinen Rechner leicht die nächsten paar hundert Jahre komplett auslasten wirst.

 

[temi]

Keine Ahnung, wie das Spiel funktioniert und aus der Beschreibung, geht das nicht genau genug hervor.

Im einfachsten Fall haben beide Spieler am Schluss eine bestimmte Anzahl von Karten in der Hand und deren Wert wird verglichen. Die Karten stammen aus eine endlichen Anzahl von Karten (dem Stapel halt). Die ganze "Zieherei" muss man dann nicht abbilden, weil die Karten auf der Hand sind immer eine Kombination aus den im Stapel (noch) verfügbaren. Das musst du halt alle möglichen Kombinationen abbilden und vergleichen.

Aber wie gesagt, keine Ahnung von den Regeln.

 

[White_Fox]

Um noch was zur Themenüberschrift beitzutragen:
Ich würde keine Überlegungen daran verschwenden welcher Datentyp am schnellsten gerechnet werden kann. Wenn du in Java arbeitest hast du praktisch keinerlei Kontrolle darüber, was wie schnell geht. Oft sind Berechnungen mit Integern schneller als mit Floats oder Doubles, andererseits gibt es auf Hardwareebene sehr wunderliche Optimierungstechniken wie z.B. Pipelines. Dann kommt es durchaus auch darauf an wie dein Programm aufgebaut ist...ein Befehl kann, wenn er einmal ausgeführt wird, eine gewisse Zeit benötigen, aber deutlich beschleunigt werden wenn er mehrmals hintereinander ausgeführt wird. Nehmen wir mal an, ein Operationsbefehl benötigt in Einzelausführung 10 Takte, wenn er aber in der Pipeline ausgeführt wird nur noch 6 Takte.

Die Zahlen sind jetzt sehr an den Haaren herbeigezogen...heutige Rechner führen mehrere Befehle pro Takt aus, und mit solchen Scherzen wie spekulativer Befehlsausführung wird es im Mittel zwar schneller, aber wie schnell genau kann dir niemand mehr sagen, das muß man ausprobieren. Dann kommt noch hinzu, wieviel Rechenzeit dein Betriessystem deinem Programm zuweist, und noch etliche andere Dinge.

Das Beste wird sein, erstmal wie von temi vorgeschlagen, auf Algorithmenebene zu optimieren. Die schnellsten Berechnungen sind diejenigen, die du gar nicht erst ausführen mußt.
Und wenn du DANN immer noch optimieren willst, dann macht man das in Assembler oder gar nicht. In Hochsprachen wie z.B. Java zu optimieren ist jedenfalls völliger Blödsinn. Du hast etliche Abstraktionsebenen zwischen deiner Hochsprache und den am Ende ausgeführten Berechnungen:

1. Die Programmiersprache selbst (unerheblich ob Java oder was hardwarenahes wie z.B. C). Das ist schon daran erkennbar, wie frei der Compiler bezüglich Optimierungen ist. Was glaubst du z.B. noch kontrollieren zu können, wenn du an einem Schieberegler einstellen kannst ob der Compiler eher auf Geschwindigkeit oder Speicherbedarf optimieren soll? Und sobald du einen anderen Compiler (oder den gleichen Compiler in einer neuen Version) hast, ist wieder alles anders.
2. In Java kommt noch die virtuelle Maschine als Abstraktionsebene hinzu, auf der Java läuft.
3. Und dann ist da noch dein Betriebssystem. Das mit hoher Wahrscheinlichkeit nicht echtzeitfähig ist. Wenn es echtzeitfähig wäre, dann wäre es zumindest möglich eine Aussage über die zur Verfügung gestellten Rechenzeit zu treffen. Wobei du dir jetzt überlegen kannst was vorteilhafter ist: Ein gesichertes Kontigent an Rechenzeit, das zwar stets garantiert, aber auch nicht übertroffen wird wenn mehr Rechenzeit zur Verfügung steht, oder gar keine Garantie für irgendwas, aber dafür sowas wie den guten Willen, zur Verfügung zu haben was derzeit möglich ist.
4. Und dann sind da noch zig andere, tieferliegende Abstraktionsebenen. Hardwareabstraktion, Microcode, und so weiter...

Selbst wenn du tief genug in all dem ganzen Kram drinsteckst (was mittlerweile unmöglich ist): Kommt ein Update von irgendwas, ist alles wieder anders.

Also wie gesagt: Die beste Optimierung ist die auf Algorithmenebene. Wenn du vieles überspringen und auslassen kannst, gewinnst du am meisten.

 

[berndoa]

Keine Ahnung, wie das Spiel funktioniert und aus der Beschreibung, geht das nicht genau genug hervor.

Im einfachsten Fall haben beide Spieler am Schluss eine bestimmte Anzahl von Karten in der Hand und deren Wert wird verglichen. Die Karten stammen aus eine endlichen Anzahl von Karten (dem Stapel halt). Die ganze "Zieherei" muss man dann nicht abbilden, weil die Karten auf der Hand sind immer eine Kombination aus den im Stapel (noch) verfügbaren. Das musst du halt alle möglichen Kombinationen abbilden und vergleichen.

Aber wie gesagt, keine Ahnung von den Regeln.

so im Prinzip ist es auch.
Am Ende vom Spiel hat halt bspw. A 2 bestimmte Karten auf der Hand und B 2 bestimmte karten auf der hand.

Natürlich kann ich anhand dessen Ableiten wer gewonnen hat.
da ich, von randomness ausgehe (karten zählen wollen wir mal sein lassen), weiß ich ja mit welcher wahrshceinlichkeit in etwa welche karte gezogen wird und kann mir daher für {{As, bube}, {7, 1}} die wahrshcienlichkeit berechnen mittels
P(As)*P(bub)*P(7)*P(1).
so in etwa, simple stochastik halt.

Sache ist halt nur dass ich es im prinzip durchspielen muss (oder auch nicht) weil es bspw. regeln gibt, wenn 2 karten von A gezogen wurden und deren wert ist dies und jenes, dann wird eine 3. karte gezogen. oder auch nicht.

die regeln wann B eine 3. karte zieht, sind noch viel abgedrehter (will sagen, ich habe noch keine seite gefunden, die sie überhaupt gut erklärt. noch etwas googeln nötig)

@White_Fox:
Optimierungen sind natürlich auch eine Sache, aber hierzulande regt man sich mal gern auf wenn ich knallhart Alles in EINER Klasse und nur mit simpen Sachen wie Arrays mache (sdie Profis hier werfen sich ja Enums, Klassen, Interfaces, etc. um die Ohren, wo ich nicht im BGeringsten durchblicken würde).

Vermutlich würde man mir hier empfehlen, eine Klasse für die Spielerhand(A im beispiel) zu haben, eine für die Bank (B im Beispiel),
selbstredend eine Spielfeld Klasse, vermutlich für jeden Mist noch extra Handlerklassen und Co. (mancher benutzt ja auch liebend gern Stringbuilders und Ähnliches, wo es auch ein +"" zum Umwandeln in einen String tut).

Frage wäre halt generell wie ich das durchspiele und strukturiere damit man am Ende nicht den Überblick verliert.

so extrem viel verschiedene Szenarien dürfte es nicht geben, es gibt, wenn ich mal so nachdenke , im Prinzip Karten mit den Werten 0-9 (duh, weil modulo 10 Alles).
Also 10 möglichkeiten pro Karte, wenn A max. 3 Karten und B max 3 Karten haben kann,
wären das so um die 10^6 möglichkeiten, also ne Million Möglichkeiten und damit ine Million SPiele, die ich einmalig zu Ende spielen müsste.

Wobei Zeit ja nicht wirklich von belang für mich ist, solange es mir den Computer nicht crasht, kann das ruhig eine Weile laufen.

Wobei es vermutlich am Sinnvollsten wäre, für jedes mögliche Spiel mir einfahc mal die Endsituation rauszufinden und in einer Liste abzuspeichern.
Und hinterher dann mit den gesammelten Endzuständen sozusagen das Nötige berechnen.



Vermutlich brauche ich hier, wie man es als Konventionshuldiger und ZwangsOOPler gerne macht, keine zig Klassen, für Spieler, bank, Spielfeld, Simulation, etc. pp. (wie es in jeder OOP Übungsaufgabe verlangt werden würde), sondern ich kann vermutlich einfach mit einem Array der Tiefe 2 arbeiten.

Und mir halt für jedes Spiel das End-Doppelarry abspeichern und später alle auswerten.

Also simples Arraybearbeiten.

Hantieren mit Arraylist wäre auch vermutlich eine Option aber ausser wo ich einem 2kartenarray noch eine 3. karte hinzufügen und das Array eben um 1 Länger machen muss, gibt es ja nicht so viele probleme mit der Arraylänge.
Sodass es "Werte kopieren in ein um 1 längeres array und neuen Wert hintendran klatschen" vermutlich schon tut



Vielleicht sollte ich irgendwann mein hübsches Lottospiel von damals mal wieder angucken und etwas ausbessern.

Gibt es eigentlich ueine gute Vorgehensweise wenn ich bei einem Problem z.b. oft prüfen muss ob die zahlen in einem 3er array in einem anderen array der länge 6 enthalten sind?
Also gibts da datentyptechnisch was besseres?
bei arrays müsste ich ja bspw. falls nicht aufsteigend sortiert, für jede der 3 zahlen aus Array A Array B einmal durchgucken.
also 3 mal das array durchlaufen.

 

[Staarfightaar]

Also gibts da datentyptechnisch was besseres?

Also prinzipiell

Egal welche Datenstruktur in egal welcher form du wählst : einen Tod stirbst du immer

du musst halt entscheiden worauf du verzichten kannst

 

[White_Fox]

Frage wäre halt generell wie ich das durchspiele und strukturiere damit man am Ende nicht den Überblick verliert.

Nun, genau deswegen würde man dir hier raten, eben nicht alles knallhart in einer Klasse zu machen, dir im Gegenteil zu einem vernünftigen Klassenaufbau raten. Und dir von simpler Arbeit mit Arrays abraten würde.

Zwangs-OOPler, Konventionshuldiger, ...ich sags mal so: Die meisten Konventionen gibt es nicht umsonst. Irgendwann habe ich mich oft genug in meinem eigenen Projekt verlaufen (sogar bei recht kleinen Sachen), und muß sagen: Man kommt tatsächlich erstaunlich viel weiter, wenn man so ein paar Tips befolgt.

Ich meine, wie oft kommt es hier vor das jemand mit irgendeiner Aufgabe kommt, alles mit Arrays macht (am besten noch mehrere Arrays synchron halten muß weil er keine Klasse schreiben wollte, um zusammengehörende Integers und Strings zusammenhalten zu können), und dann mit viel Aufwand ein eigentlich schon volles oder gar mehrere volle Arrays erweitern will?
So einfach wie Arrays dir erscheinen mögen - ArrayLists sind einfacher. (Und wo ArrayLists nicht gut oder passend sind, sind es Arrays erst Recht nicht.)

Ich will dir keine Vorgehensweise vorschreiben, das ist deine Sache. Aber wenn jemand um Hilfe bittet und ich bekomme dann das Resultat deiner eben dargestellten Arbeitseinstellung vorgelegt...ich sag mal so, ich habe auch noch andere Dinge zu tun.
Anders gesagt, sauber strukturierter Code ist auch hilfreich, wenn man andere um Hilfe bittet.
Quellcode ist niemals ein Selbstzweck, sondern stets nur ein Mittel. (Und wenn der Zweck nur ist, daß du Programmieren lernen willst.)
Bei aller Hilfsbereitschaft, aber niemand will sich durch einen Wust an unleserlichem, unstruktiertem Mist abarbeiten.

 

[Robert Zenz]

Ich bitte um Verzeihung, ich habe jetzt nicht alle Beitraege gelesen, aber das Problem klingt eigentlich relativ simpel. Wenn du ein Kartenspiel von Ass bis Koenig hast, sind das 4x13 Karten, also 52. Das kann man sich schon als Enum anlegen, das ist eine verschwindend geringe Menge. Diese Karten schiebst du dann in eine Liste, mischt diese und ziehst dann immer zwei aus der Liste und kontrollierst wer diese Runde gewonnen hat, rechnest am Ende die beiden Spielerstapel zusammen nach deinen Regeln. Entweder habe ich hier etwas grob fahrlaessig uebersehen, oder ist eigentlich egal welchen Datentyp du hier nimmst, weil so interessant grosz ist der Zustand nicht, sage ich mal.

Was viel schwieriger sein wird, ist das nachvollziehbare mischen der Karten. Du musst alle Misch-Moeglichkeiten durchgehen, und wenn du nicht jedes Kartenspiel abspeichern willst, musst du dir hier eine nachvollziehbare Variante ueberlegen. Also zum Beispiel Kartenspiel #5748 ist immer genau so gemischt. Das kannst du aber nicht wirklich per Zufall machen, weil du die Kartenspiele ja eigentlich gezielt durchgehen willst. Das ist ein Problem, da muesste ich jetzt darueber nachdenken wie man das macht.

Das Zweite sind die Anzahl der moeglichen Kartenspiele. Das sind bei 52 Karten 8*10^68 wenn ich mich nicht verzaehlt habe. Die Idee das durchzugehen kannst du knicken! Selbst bei 50 Milliarden Kombinationen die Sekunde wirst du nicht vor dem Hitzetod des Universums fertig. Also was du im besten Fall machen kannst, ist ein paar Milliarden moegliche Spiele zu analysieren. Und bei der Menge spielt weder Datentyp noch Algorithmus eine allzu grosze Rolle, behaupte ich.

 

[Robert Zenz]

Wenn du das als Uebung machen willst, dann wuerde ich einfach mal anfangen das zu tippen und dann darauf aufbauen. Du wirst relativ schnell irgendwelche Engpaesse finden, zum Beispiel beim Speicher und CPU, und dann kannst du dort gezielt ansetzen und verbessern. Auch kannst du dann hier ein "gezieltes" Thema aufmachen dann mit dem was du dann hast.

 

[mihe7]

Das sind bei 52 Karten 8*10^68 wenn ich mich nicht verzaehlt habe. Die Idee das durchzugehen kannst du knicken

Wie kommst Du denn auf die Zahl?

 

[temi]

Wenn du ein Kartenspiel von Ass bis Koenig hast, sind das 4x13 Karten, also 52.

Soweit ich richtig nachgelesen habe, spielt man Baccara mit 6 französischen Kartensets. Es sind also mindestens 6 x 52 Karten (wobei ich grad nicht genau weiß, wie viele Karten in einem Französischen Blatt sind).

Was viel schwieriger sein wird, ist das nachvollziehbare mischen der Karten. Du musst alle Misch-Moeglichkeiten durchgehen, und wenn du nicht jedes Kartenspiel abspeichern willst, musst du dir hier eine nachvollziehbare Variante ueberlegen. Also zum Beispiel Kartenspiel #5748 ist immer genau so gemischt. Das kannst du aber nicht wirklich per Zufall machen, weil du die Kartenspiele ja eigentlich gezielt durchgehen willst. Das ist ein Problem, da muesste ich jetzt darueber nachdenken wie man das macht.

Das wollte ich auch erwähnen. Zufall ist in dem Fall wohl schlecht, weil du ja oben geschrieben hast, dass du systematisch alle Kombinationen testen möchtest. Mit Zufall kannst du (zumindest nicht ganz einfach) nicht garantieren, ob du alle Kombinationen gespielt hast.

Spielen eigentlich immer nur zwei Spieler gegeneinander?

Vermutlich brauche ich hier, wie man es als Konventionshuldiger und ZwangsOOPler gerne macht, keine zig Klassen, für Spieler, bank, Spielfeld, Simulation

Vermutlich ist das so. Ich tendiere in Richtung Karte, Deck und Regeln für die Ausgabe der dritten Karte. Letztlich bekommt jeder Spieler (so ich das richtig verstehe) auf jeden Fall zwei Karten und dann noch eine Dritte, falls die Regel erfüllt ist. Anschließend wird abgerechnet.

Die genaue Karte ist vermutlich sogar unwichtig, weil es nur um den Punktwert der Karte geht. Du hast also eine Menge mit Punktwerten von 0 bis 9, die sich dann systematisch kombinieren lassen.

Edit: Als erstes solltest du dir die Frage stellen, welche Erkenntnis du daraus gewinnen möchtest. Also ganz konkret. Du weißt ja schon, dass der Stapel 4 (Farben) x 9 (Werte) x 6 (Kartensets) = 216 Karten mit einem Wert und 96 Karten mit dem Wert 0 enthält. Daraus lassen sich ja schon Wahrscheinlichkeiten berechnen ohne überhaupt etwas "simuliert" zu haben. Das gilt dann natürlich auch für die dritte Karte.

 

[temi]

Du weißt ja schon, dass der Stapel 4 (Farben) x 9 (Werte) x 6 (Kartensets) = 216 Karten mit einem Wert

Du weißt sogar noch mehr, denn 24 Karten haben den Wert 1, 24 Karten den Wert 2, usw.

Du kannst also die Wahrscheinlichkeiten für eine bestimmte Punktzahl berechnen. Zusammen mit den Regeln für die dritte Karte, z. B. bei 0-4 Punkten muss vom Spieler eine Karte gezogen werden, kannst du weitere Wahrscheinlichkeiten berechnen und den Wahrscheinlichkeiten, die sich durch die Regeln für die Bank ergeben, gegenüberstellen.

es geht mir um den harten Mathekern.

Das also ist des Pudels Kern

Warnung! Ich bin kein Mathematiker, also alles ohne Gewehr (Gewähr)!

 

[Robert Zenz]

Wie kommst Du denn auf die Zahl?

Ich nichts Mathe, aber das muessten doch 52! sein, oder irre ich mich da?

Aber jetzt wo du es sagst, habe mich doch verzaehlt, sollten 8*10^67 sein...

 

[Marinek]

Bei Karten ist es ziehen ohne zurücklegen. Mithin, wenn du 1, 2, 3 hast und legst deine Rechnung zu grunde, dann hättest du auch solche Optionen:

1 1 1
2 2 2
3 3 3

Das ist aber nicht möglich. Daher, 1. Karte 3, zweite KArte 2, dritte Karte 1 (3!)

 

[mihe7]

Ich nichts Mathe, aber das muessten doch 52! sein, oder irre ich mich da?

Nein, 52! wäre die Anzahl an Permutationen von 52 Karten, damit beantwortest Du die Frage nach der Zahl der Kombinationsmöglichkeiten von 52 Karten (Anzahl unterschiedlicher Ergebnisse beim Mischen).

Da die Farben nicht sondern nur die 13 Werte interessieren, außerdem nur eine begrenzte Zahl an Karten gespielt wird und ausreichend Karten vorhanden sind, ist die Zahl der möglichen Spiele bei n gespielten Karten begrenzt auf 13^n und jeder Spielstand lässt sich als Zahl zur Basis 13 darstellen.

 

[Robert Zenz]

Nein, 52! wäre die Anzahl an Permutationen von 52 Karten, damit beantwortest Du die Frage nach der Zahl der Kombinationsmöglichkeiten von 52 Karten (Anzahl unterschiedlicher Ergebnisse beim Mischen).

Da die Farben nicht sondern nur die 13 Werte interessieren, außerdem nur eine begrenzte Zahl an Karten gespielt wird und ausreichend Karten vorhanden sind, ist die Zahl der möglichen Spiele bei n gespielten Karten begrenzt auf 13^n und jeder Spielstand lässt sich als Zahl zur Basis 13 darstellen.

So genau hatte ich nicht gelesen.

 

[mihe7]

So genau hatte ich nicht gelesen.

Das Fiese an der Sache ist, dass man bei solchen Aufgabenstellungen irgendwie dazu neigt, sofort an Permutationen, Binomialkoeffizienten etc. zu denken. Geht zumindest mir so.

 

[Robert Zenz]

Das Fiese an der Sache ist, dass man bei solchen Aufgabenstellungen irgendwie dazu neigt, sofort an Permutationen, Binomialkoeffizienten etc. zu denken. Geht zumindest mir so.

Ja, ich weisz was du meinst.

Wobei ich dann wieder bei meiner Meinung bin dass Aufbau und Algorithmus nicht unmittelbar eine Rolle spielen bei der Anzahl an Moeglichkeiten.

 

[mihe7]

Wobei ich dann wieder bei meiner Meinung bin dass Aufbau und Algorithmus nicht unmittelbar eine Rolle spielen bei der Anzahl an Moeglichkeiten.

Geht es nur darum, alle möglichen Spielsituationen durchzuspielen, kann man auf den Zufall verzichten und bildet halt für die vier initialen Karten die 13^4 ~ 29 Tsd. Möglichkeiten.

Will man näher am echten Spiel sein, müsste man aus 312 Karten vier auswählen. Da gäbe es dann 312 über 4 ~ 388 Mio. Möglichkeiten (mit vielen Duplikaten).

Will man das Ganze per Zufall erledigen, dann braucht man sich über Laufzeiten keine Gedanken mehr zu machen. Aber man könnte Aussagen auf eine begrenzte Zahl zufällig gewählter Spiele treffen.

 

[berndoa]

Wie kommst Du denn auf die Zahl?

Ich habe das nicht gesagt

Soweit ich richtig nachgelesen habe, spielt man Baccara mit 6 französischen Kartensets. Es sind also mindestens 6 x 52 Karten (wobei ich grad nicht genau weiß, wie viele Karten in einem Französischen Blatt sind).


Das wollte ich auch erwähnen. Zufall ist in dem Fall wohl schlecht, weil du ja oben geschrieben hast, dass du systematisch alle Kombinationen testen möchtest. Mit Zufall kannst du (zumindest nicht ganz einfach) nicht garantieren, ob du alle Kombinationen gespielt hast.

Spielen eigentlich immer nur zwei Spieler gegeneinander?


Vermutlich ist das so. Ich tendiere in Richtung Karte, Deck und Regeln für die Ausgabe der dritten Karte. Letztlich bekommt jeder Spieler (so ich das richtig verstehe) auf jeden Fall zwei Karten und dann noch eine Dritte, falls die Regel erfüllt ist. Anschließend wird abgerechnet.

Die genaue Karte ist vermutlich sogar unwichtig, weil es nur um den Punktwert der Karte geht. Du hast also eine Menge mit Punktwerten von 0 bis 9, die sich dann systematisch kombinieren lassen.

Edit: Als erstes solltest du dir die Frage stellen, welche Erkenntnis du daraus gewinnen möchtest. Also ganz konkret. Du weißt ja schon, dass der Stapel 4 (Farben) x 9 (Werte) x 6 (Kartensets) = 216 Karten mit einem Wert und 96 Karten mit dem Wert 0 enthält. Daraus lassen sich ja schon Wahrscheinlichkeiten berechnen ohne überhaupt etwas "simuliert" zu haben. Das gilt dann natürlich auch für die dritte Karte.

Öh, ehm, keine Ahnung?

Erstmal: Wie ich schon schrieb, will ich nicht davon ausgehen dass irgendwie x Decks benutzt werden und, auf gut Deutsch gesagt, kartenzählen oder in die Richtung gehen.

Ich gehe einfahc davon aus dass es von jeder Karte unendlich viele gibt, Alle also gleich wahrscheinlich mit 1/13 Wahrshceinlichkeit gezogen werden.
Weil es halt die 13 verschiedenen Karten 1-9,Bube, Dame, könig, Ass gibt.
Wie jemand shcon sagte, ist bei Baccarat die Zuordnung wie folgt:
Karte 1-9 Wert=1-9 (also halt gleicher Wert wies draufsteht)

bube dame könig werden auf den Wert 0 abgebildet (gedanklich merke ich mir das als 10 mod 10 weil mahct sinn)
Ass hat den wert 11 mod 10=1

wie auch jemand sagte, gibt es de facto also nur die Wertkategorien
0-9.

wobei die anzahl karten, die den gleichen wert haben, nicht gleich ist:
wert 0 haben 3 karten (bube, dame, könig).
wert 1 haben 2 karten (die 1 und ass)
wert 2-9 gibt es jeweils nur 1 karte

demnach, falls eine karte gezogen wird, ist es 3/13 wahrshceinlichkeit eine wert 0 karte, mit 2/13 WS eine Wert 1 karte und mit jeweils 1/13 eine karte mit wert 2-9.


Daher die wahrscheinlichkeit für einen Endzustand zu bestimmen ist daher easy wenn bspw. weiß welche 2 karten der spieler und welche 3 karten der gegner hat.

ich will nur die einzelnen spiele durchgehen, weil in manchen spielen im Endzustand spieler und Bank je nur 2 karten haben, in anderen fällen hat der spieler 3 karten und die bank 2 karten, etc.
weil halt je nach spiel spieler und bankhand am ende mal 2 karten, mal 3 karten groß ist.

daher will ich, so sinnbildlich wie im entscheidungsbaum, von der wurzel aus das ganze durchspielen.

@temi so wie ich es (bisher) verstanden habe, spielt nur der spieler gegen die bank, also 2 teilnehmer und bis auf den zufall beim kartenziehen ist der ablauf auch vorgegeben. Also nicht wie beim schach oder so wo spieler A oder B wahlmöglichkeiten haben.

@Apple’s Jünger:
Ich würde eher mit zurücklegen annehmen aus dem einfahcen grund weil ich das Spiel dahingehend betrachten will wie wenn man es im Onlinecasino spielt.
Da gibts ja auch kein endliches Deck, sondern faktisch wirft ein zufallsgenerator eine random karte raus.
Also es gibt kein "das Ass des Decks wurde shcon gespielt, also kann als näcjhster nur eine der anderen 12 Karten kommen".


Natürlich könnte man es auch ohne zurücklegen betrachten, nur wie gesagt, onlinecasino ist mit zurücklegen und auch im realen Casino weiß man vielleicht gar nicht wie viele Decks da in der Kartenmischmaschine drin sind oder wie es funktioniert.
Es fehlen einfach die nötigen hintergrundinfos zum Kartezählen

@mihe7 : ja, zufällig Pfeile werfen (sinnbildlich) will ich nicht, sondern alle kombinationen für das ziehen von 6 (oder halt wengier) Karten durchgehen.
Wobei, dank der Wertzuordnung, es "nur" 10 verschiedene werte und damit 10^6 verschiedene Spiele und Spielverläufe gibt.

 

[mihe7]

Wobei, dank der Wertzuordnung, es "nur" 10 verschiedene werte und damit 10^6 verschiedene Spiele und Spielverläufe gibt.

Dann ist es ja noch einfacher: einfach alle Zahlen bis 9999 oder 999999 durchgehen - fertig.

 

[temi]

Ich gehe einfach davon aus dass es von jeder Karte unendlich viele gibt

Das ist aber ein Widerspruch zu diesem

wobei die anzahl karten, die den gleichen wert haben, nicht gleich ist:
wert 0 haben 3 karten (bube, dame, könig).
wert 1 haben 2 karten (die 1 und ass)
wert 2-9 gibt es jeweils nur 1 karte

Unendlich ist unendlich. Und die Hälfte von Unendlich ist immer noch unendlich. Genauso wie 1/13 von Unendlich auch immer noch unendlich viele sind.

Außerdem passt deine Aufstellung nicht:

Im französischen Blatt gibt es keine 1. Die Zahlen gehen von 2 - 10. Es gibt vier Farben und in allen vier Farben alle Werte oder Bilder.

Also:
wert 0 haben 4 x 4 Karten (bube, dame, könig, 10).
wert 1 haben 4 x 1 Karten (das Ass)
wert 2-9 gibt es jeweils 4 Karten.

Aber, ganz ehrlich, mit deinen Prämissen, halte ich das ganze für relativ sinnlos, weil die Wahrscheinlichkeit welchen Wert die nächste Karte hat, eben davon abhängt, welche Karten überhaupt im Spiel sind.

 

[berndoa]

Huh, das es keine 1 gibt, wusste ich auch nicht.
Gibt es doch aber in den meisten Decks? :O


Naja, sinnlos ist relativ.

Für jede Karte 100% Wahrshceinlichkeit anzunehmen wäre genauso witzlos.

Aber wenn ihr unbedingt Kartenzählen wollt, bitte.
Also ich weiß nicht mit welcher Deckanzahl so ein Zufallszahlengenerator im onlinecasino operiert.

Aber gut, man kann halt auch annehmen der wäre ein realer Mensch mit nur einem Deck in der Hand und wir hätten da bedingte Wahrscheinlichkeiten...

 

[berndoa]

Nun, genau deswegen würde man dir hier raten, eben nicht alles knallhart in einer Klasse zu machen, dir im Gegenteil zu einem vernünftigen Klassenaufbau raten. Und dir von simpler Arbeit mit Arrays abraten würde.

Zwangs-OOPler, Konventionshuldiger, ...ich sags mal so: Die meisten Konventionen gibt es nicht umsonst. Irgendwann habe ich mich oft genug in meinem eigenen Projekt verlaufen (sogar bei recht kleinen Sachen), und muß sagen: Man kommt tatsächlich erstaunlich viel weiter, wenn man so ein paar Tips befolgt.

Ich meine, wie oft kommt es hier vor das jemand mit irgendeiner Aufgabe kommt, alles mit Arrays macht (am besten noch mehrere Arrays synchron halten muß weil er keine Klasse schreiben wollte, um zusammengehörende Integers und Strings zusammenhalten zu können), und dann mit viel Aufwand ein eigentlich schon volles oder gar mehrere volle Arrays erweitern will?
So einfach wie Arrays dir erscheinen mögen - ArrayLists sind einfacher. (Und wo ArrayLists nicht gut oder passend sind, sind es Arrays erst Recht nicht.)

Ich will dir keine Vorgehensweise vorschreiben, das ist deine Sache. Aber wenn jemand um Hilfe bittet und ich bekomme dann das Resultat deiner eben dargestellten Arbeitseinstellung vorgelegt...ich sag mal so, ich habe auch noch andere Dinge zu tun.
Anders gesagt, sauber strukturierter Code ist auch hilfreich, wenn man andere um Hilfe bittet.
Quellcode ist niemals ein Selbstzweck, sondern stets nur ein Mittel. (Und wenn der Zweck nur ist, daß du Programmieren lernen willst.)
Bei aller Hilfsbereitschaft, aber niemand will sich durch einen Wust an unleserlichem, unstruktiertem Mist abarbeiten.

"Quellcode ist niemals ein Selbstzweck, sondern stets nur ein Mittel."

Ein Mittel zum Zweck, das nicht unbeingt schön sein muss, sondern funktionieren muss.

 

[Staarfightaar]

"Quellcode ist niemals ein Selbstzweck, sondern stets nur ein Mittel."

Ein Mittel zum Zweck, das nicht unbeingt schön sein muss, sondern funktionieren muss.

nicht wirklich...das war vor der software krise

du musst halt kein hello world optimieren , weil
1. du weist dass es danach fertig ist
2. in zukunft nix mehr passieren wird
3. es sowieso so kurz ist dass es witzlos ist

die programme die du schreibst passen "gefühlt" nicht zu java ... python wurde für sowas gemacht

in python konzentrierst du dich nur auf die mathematik und keine klassen und blabla.. deswegen ist es auch so erfoglreich... dass du dafür an anderer stelle aufs maul kriegst muss idr halt auch klar sein

powershell würde es auch tun in diesem fall
weil die darauf ausgelegt sind kleine probleme blitzschnell zu lösen... wahrscheinlich kannst du das lotto ding in powershell in 10 zeilen packen und jut is

was ich halt nicht versteh
1. chinesisch
2. warum du mit der so ziemlich am meisten verbunden sprache mit oop es versuchst funktional hinzu kriegen

 

[KonradN]

Haha ... @Staarfightaar - Du wirst diesen erbitterten Gegner nicht in unsere Sekte hinein kriegen. Verschwende daher nicht Deine Zeit. In der Zeit kannst Du bei mind. 10 Anderen eine Gehirnwäsche vollziehen damit sie unserer Sekte treu dient und wir wieder einen Schritt weiter kommen: Die Weltherrschaft ist zum greifen nahe!

*scnr*

 

[mihe7]

Ein Mittel zum Zweck, das nicht unbeingt schön sein muss, sondern funktionieren muss.

Schön muss er nicht sein, zumal das im Auge des Betrachters liegt. Vernünftig lesen muss man ihn können.

Mein Java EE-Stammprojekt ist mittlerweile über 10 Jahre alt, hat irgendwas zwischen 100.000 und 120.000 Zeilen Code und etwa 500 Klassen.

Der Code ist weit von Perfektion entfernt ("historisch gewachsen") aber wir sind auch heute noch in der Lage, Anforderungen in kurzer Zeit umzusetzen. Das funktioniert aber nur, weil a) die Grundsatzentscheidungen z. B. zum Design richtig waren und b) ein gewisses Maß an Pflege des Codes dahintersteckt.

Wenn da jeder drin rumschreiben würde, ohne sich an irgendwas zu halten, wäre das Projekt nach einem halben Jahr tot. Das Programm würde vielleicht funktionieren aber sobald eine neue Anforderung reinkommt, hättest Du einen solchen Aufwand, dass sich dieser nicht mehr rechnet.

Ab und zu komme ich an solche Stellen im Code, die schreibe ich dann um, denn einmal zwei Tage in die Tonne treten muss reichen.