Wie ich die Aufgabe verstanden habe, geht es darum, zu ermitteln, welche Karten das Programm behalten und welche es ablegen soll.
Dann würde ich mich auch genau darum kümmern. Dann spielen nähmlich erstmal die anderen Karten keine Rolle.
Ich würde ein Array mit den einzelnen Treffern aufbauen und die erhaltenen Karten der Programms damit abgleichen.
Im Array sind also alle Treffer enthalten, also auch alle gültigen Kombinationen einer Straße oder eines Full House usw.
Die gültigen Kombinationen kann ja ein Programm erstellen und das Array füllen.
Das Array soll aufsteigend der Wertigkeiten der Pokerregeln sortiert sein.
Dann wird ein Vergleich der Hand mit dem Array durchgeführt.
Die höchste Wertigkeit wird ermittelt und behalten, der Rest abgelegt.
Wenn kein Treffer( ab Paarung/ Ass kann auch ein Treffer sein oder auch jedes als sinnvoll erscheinende unvollständige Ausgangsblatt) vorhanden, soll die Überprüfung nicht auf 100%ige Übereinstimmung, sondern auf -1 Karte geprüft werden.
Der höchste key wird ausgewählt, die Karten, die nicht beteiligt sind, werden abgelegt.
Wenn immer noch kein Treffer, nochmal auf -2/-3 Karten prüfen.
Wenn immer noch kein Treffer und ein Spieler setzt x/Pott = passen.
Damit sollte die Anforderung erfüllt sein.
Die Wahrscheinlichkeiten kommen ins Spiel, wenn es darum geht, das aktuelle Blatt ins Verhältnis zum Pott, zur Anzahl der Mittspieler und zum aktuellen Setzen eines Mitspielers zu setzen.
Gibt es die Funktion, Beiträge als erledigt zu kennzeichnen?
Wenn nicht, sei dies ein Verbesserungsvorschlag.
Was mich zum Thema Poker interessieren würde ist die Frage der Wahrscheinlichkeiten.
Sagen wir mal, wir spielen Online Poker und haben nebenbei ein Programm laufen, das die Wahrscheinlichkeiten meines Blattes auf Gewinn berechnet bzw wie hoch die Wahrscheinlichkeit zum erhalten einer bestimmten Karte ist bzw wie hoch die Wahrscheinlichkeit ist, das Mitspieler höhere Blätter haben wie wir.
welche form von poker meinst du. dieses deppige texas hold 'em? oder die einzig vernünftige variante five card draw? btw. das war für ein tutorial über literal-objekte gedacht. mehr nicht
peter
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson) Meine Seite
Das Problem an Poker ist, dass ein normaler Server viiiiel zu wenig Leistung dafür hat. Ansonsten wäre es ziemlich einfach ein von der Wahrscheinlichkeit her gesehen perfektes Pokerspiel zu erstellen.
Estrela, dein Vorschlag mit einer Datenbank ist eine einfache Variante, aber hast du bereits einmal die Anzahl Möglichkeiten berechnet? Selbst bei einem Bitfeld brauchst du noch mindestens 8 Byte pro Möglichkeit und das ist für heutige PCs immer noch viiiel zu viel.
Ich weiß jetzt nicht, ob du mich richtig verstanden hast.
Mein Vorschlag ging dahin, ein gewissermaßen holographisches Abbild aller möglichen sinnvollen Hände einmalig von einem Programm zusammenstellen zu lassen und dieses in einer Datei oder auch in einer Datenbank abzuspeichern.
Zur Laufzeit des Scriptes braucht dann nur noch verglichen zu werden, mit welcher gespeicherten Hand die aktuelle am besten übereinstimmt und die zur Übereinstimmung nicht benötigten Karten einfach ablegt.
Das wird doch nicht so eine hohe Auslastung des Arbeitsspeichers benötigen.
Es gibt 1.302.540 sinnvolle Hände à 5 Karten. Bei 52 Karten braucht man nur 6 Bit pro Karte (fixed width alignment). Das "Hologramm" benötigt im Idealfall nur 7.815.240 Bit bzw. rund 950 KB. Wenn man wie bei PHP für jeden Wert gleich 32 Bit ver(sch)wendet und nicht gezielt in den Speicher greifen kann, sondern Datenstrukturen wie Arrays nutzen muss, braucht das "Hologramm" schon über 10 MB. Das ist zwar deutlich mehr, aber für "heutige PCs" kein Problem.
Dein "Hologramm" ist übrigens der Idee mit dem Graphen sehr ähnlich.
Also erstmals muss ich zugeben, dass ich nicht alles durchgelesen habe...
Ich dachte es gehe um die Wahrscheinlichkeitsrechnung beim Pokern also um eine von der Wahrscheinlichkeit her gesehen perfekte AI. Und das ist für Texas Holdem nicht möglich.
Die Möglichkeit ein "Hologramm" zu erstellen bezweifle ich jedoch nicht deine Rechnung hingegen ist jedoch meiner Meinung nach etwas falsch.
Mit 6 bit kannst du zwar eine ein Bitfeld für eine Karte erstellen, aber nicht für eine Hand.
Pro Hand brauchst du für das Bitfeld mindestens 52 bits.
Man käme mit einem numerischen Feld zwar sogar bereits mit 20 bits aus, 30 für eines mit geteilten sektoren, aber dabei ist nr 1 extrem langsam und nummer 2 auch immer noch sehr langsam. Dann wäre sogar ein zweidimensionales Array noch schneller. Aber insbesonder bei 64bit Maschinen, aber auch bei 32Bit zeigt sich der Nachteil des Arrays gegenüber dem Bitfeld, welches zwischen den einzelnen Karten nicht nach impliziten Sprüngen verlangt.
Mit 6 bit kannst du zwar eine ein Bitfeld für eine Karte erstellen, aber nicht für eine Hand.
Hab ich auch nicht behauptet. Gemeint war 2^5 = 32 < 52 < 64 = 2^6.
Pro Hand brauchst du für das Bitfeld mindestens 52 bits.
Man käme mit einem numerischen Feld zwar sogar bereits mit 20 bits aus, 30 für eines mit geteilten sektoren ...
Was redest du denn da? Eine Hand sind 5 Karten. 5 mal 6 Bit sind 30 Bit, nicht 52 oder 20!
Mit geteilten Sektoren meinst du wahrscheinlich das selbe wie ich mit fixed width alignment.
Zuletzt geändert von onemorenerd; 06.06.2009, 09:15.
Hab ich auch nicht behauptet. Gemeint war 2^5 = 32 < 52 < 64 = 2^6.
Das hab ich mir auch gedacht, aber dann hast du kein Bitfeld der Karten und es wird wie gesagt um einiges langsamer sein.
Beim Bitfeld hättest du für jede Kart genau ein Bit zur Verfügung also mindestens 52. Das bewirkt, dass eine Menge weniger Sprünge nötig sind und ausserdem wirst du weniger Male auf den RAM zugreifen müssen und weniger Prozessorfunktionen benötigen.
Und sry du hast recht, ich habe einen Rechnungsfehler gemacht bei 20 bits, es sind 22: 2^21 < (52!/(5!*47!)) < 2^22. Das wäre ein Extrem der numerischen Feldes, welches noch einiges mehr an Rechenaufwand benötigen würde.
Kommentar