06:36:01 Schrompf joined the channel
06:36:40 IceMichael: Guten Schmorgen!
07:01:38 IceMichael: Schrompf, ich hab übrigens gerade ne Struktur in der Pokeranalyse gefunden, mit der ich 95% der Ergebnisse über lookup kriegen kann
07:01:54 IceMichael: war etwas dumm, dass ich das nicht vorher gesehen hab
07:03:08 Schrompf: und Hallöle
07:03:13 Schrompf: IceMichael: freut mich
07:04:29 IceMichael: ja... es ist auch leider logisch. Wenn ich z.B. Ass herz, Ass könig auf nem 987 Herz-Flop habe, ist das ja dasselbe, als wenn alles in Karo, Pik, Kreuz ist...
07:04:49 Schrompf: das floppt hart
07:04:51 IceMichael: ich bin also einfach alle Muster durchgegangen und man kann in vielen Fällen 24 Fälle auf einen reduzieren
07:05:06 Schrompf: klingt floppsig
07:05:08 IceMichael: ja! Wieso ich so was vorher nicht sehe, muss man den Gott der kackb00ns fragen
07:05:34 Schrompf: du nutzt symmetrien aus, interpretiere ich
07:06:46 IceMichael: ja, ich nutze dhsc für die vier Farben in der Ursprungsnotation und ersetze sie durch xyzw, wobei x einfach das häufigste Vorkommen ist, y das zweithäufigste etc.
07:07:23 IceMichael: dadurch werden automatisch Gruppen erzeugt, die netterweise die gleiche Gewinn/Split-Chance haben
07:27:22 Schrompf: nicelig
07:27:27 Schrompf: nicenstein
07:27:31 Schrompf: be-nice-mittel
07:53:54 xq: moin
07:54:51 xq: IceMichael: das klingt nach einer geilen erkenntnis
07:56:27 IceMichael: xq, danke! Aber ich kann nicht anders als das runterzuspielen, eigentlich ist das ja komplett trivial
07:57:33 xq: nö, für sowas ist man ingenieur
07:59:19 IceMichael: hm, aber das ist ungefähr der Erkenntnisgrad wie "wenn rote Socken zu einem roten Pulli passen, dann passen blaue Socken vermutlich genau so zu einem blauen Pulli" :D
07:59:31 xq: das heißt nicht, dass es obvious ist ;)
07:59:38 xq: vorallem nicht in einem komplexen environment
07:59:49 IceMichael: ja gut, mein Beispiel suckt, meine Frau weist mich trotzdem häufig genug darauf hin, dass etwas nicht zusammenpasst :D
08:00:32 IceMichael: wenn ich es übrigens statt auf 5% sogar auf 0.5% reduzieren könnte, dann könnte ich für alle Ergebnisse einfach eine Lookup-Table bauen
08:00:44 IceMichael: für jede Hand gegen jede andere Hand am Flop könnte ich dann einfach nachschlagen, wie die Gewinnchance ist
08:09:54 Schrompf: kannst du vielleicht irgendwie ausnutzen, dass die hinteren farben nur noch maximal eine karte haben können
08:11:18 IceMichael: hmm, wie meinst?
08:11:45 Schrompf: naja: du sortierst die hand nach den häufigsten farben, hast du gesagt
08:12:02 Schrompf: also kannst du durchzählen, wieviele karten pro farbe maximal vorkommen können
08:12:27 Schrompf: es kann ja bei fünf karten kein 1,2,2 geben, weil du dann die fabre mit der einen karte nach hinten sortiert hättest
08:12:45 Schrompf: also kannst du z.b. mit sicherheit sagen, dass die letzthäufige farbe maximal 1 karte hat
08:13:06 Schrompf: weil wenn sie zwei hätte, wäre sie nach vorne sortiert worden und eine andere farbe wäre die letzthäufige
08:13:20 IceMichael: ja, die Permutationen hab ich eh schon raus, das meinst du, oder?
08:14:03 Schrompf: du stellst bereits die häufigste farbe mit nem bitmuster und die letzte/vorletzte farbe mit nem einfachen index?
08:14:52 IceMichael: hmmm, ich hab glaub ich die Idee noch nicht ganz kapiert
08:15:05 IceMichael: also im Endeffekt muss ich ja eh alles durchgehen, bin jetzt nicht sicher
08:15:08 Schrompf: ist jetzt fies geraten, aber:
08:15:24 Schrompf: du willst irgendwie alle möglichen kombis darstellen
08:15:59 Schrompf: und du willst ausnutzen, dass nach der sortierung der farben nach anzahl die hinteren quasi keine karten mehr haben können. weil sie sonst nach vorn sortiert wären
08:16:13 IceMichael: hm, das letzte versteh ich gerade nicht
08:16:19 Schrompf: grmpf
08:16:29 IceMichael: also ich hab alle Kombis jeweils in einem Bitmuster, das schon mal ja
08:16:34 Schrompf: du sortierst die farben in dem flop. in der hand. in dem satz karten
08:16:54 IceMichael: hmm, also zurzeit mach ich das nicht ganz. Ich gruppiere ja nur und sortiere nicht
08:16:58 Schrompf: weil du erkannt hast, dass die konkrete farbe egal ist und nur gleiche farbe interessant sind
08:17:22 IceMichael: d.h. ich nehm die Hand, zieh mir die Suits raus, konvertiere die und schau im lookup nach, ob es dafür schon nen Eintrag gibt
08:17:44 Schrompf: und deswegen gibt es bei dir kein Piek und kein Herz mehr, sondern nur noch "die farbe mit den meisten karten" und dann "die farbe mit den zweitmeisten karten"
08:17:49 IceMichael: okee, ich könnte auch auf lookup verzichten, wenn ich richtig sortieren würde und dann mit der Zahl multipliziere
08:18:19 Schrompf: stimmt das so, wie ich es bisher geschrieben habe?
08:19:01 IceMichael: ja, also die Gruppierungsidee ist richtig
08:19:30 IceMichael: ich behalte pik/herz usw. trotzdem noch, weil ich ja zumindest einmal die Gewinnchance berechnen will
08:19:39 Schrompf: ok. und jezt willst du ausnutzen, dass nach der sortierung der farben nach kartenanzahl bestimmte kombinationen nicht mehr aufteten können
08:19:58 Schrompf: du willst die anzahl einträge in deiner lookup-tabelle runterkriegen
08:20:11 IceMichael: moment kurz standup
08:20:14 Schrompf: und mein vorschlag dazu ist, dass du den key optimieren kannst
08:20:25 Schrompf: ja, ich dann auch. fortsetzung ab ~10 uhr
08:30:23 IceMichael: hmm, also aktuell hab ich die minimale Zahl von LUT-Einträgen:
08:31:16 IceMichael: schau dir die suits an, konvertiere sie in einen eindeutigen Key (eben mit xyzw wie oben beschrieben), schau ob es in LUT nen Eintrag gibt. Falls ja, nutze ihn, falls nein, berechne und lege ihn an
08:32:25 IceMichael: vermutlich werd ich einen Zwischentable für Performance bauen, bei dem ich die ursprünglichen Kartenfarben als key hab und als output direkt einen Index auf die LUT kriege
08:34:54 Schrompf: neee, das ist doch verschwendung
08:39:03 IceMichael: du würdest lieber so vorsortieren, dass klar ist, dass jeder Eintrag noch nicht berechnet wurde?
08:39:16 IceMichael: ich weiß nicht, ob das viel spart, es wäre auf alle Fälle sehr viel refactoring an meiner Stelle
08:43:10 IceMichael: also man muss dazu sagen: ich mach keine Schleifen um einzelne Karten, die irgendwo erscheinen, ich erzeuge mir vorher das Set an allen möglichen Boards
08:52:52 Schrompf: so
08:52:53 Schrompf: neeeneee
08:53:13 Schrompf: ich habe deine idee aufgegriffen, die kompletten wahrscheinlichkeiten in einer großen tabelle zu speichern
08:53:39 Schrompf: du meintest, du müsstest dazu die anzahl möglichkeiten noch auf ~0,5% reduzieren, bei 5% wärst Du bereits
08:54:58 Schrompf: ich *vermute*, du hast die 5% erreicht, indem du die kartenauswahl farbenneutral nach anzahl karten pro farbe sortierst
08:55:22 Schrompf: weil dir egal ist, ob das jetzt rot oder piek ist, solange du weißt, dass der könig und die dame von der selben farbe sind
08:55:36 IceMichael: ah, da bist du. Ja, genau
08:56:10 Schrompf: und mein gedanke ist, dass du jetzt den key, mit dem du in die lookup-tabelle schaust, weiter reduzieren kannst
08:56:56 IceMichael: meinst du damit jetzt weniger Einträge oder ein kürzerer Key?
08:57:06 IceMichael: (vermutlich beides)
08:57:35 Schrompf: beides. du hast dein blatt z.b. als bitmuster: 0b0000001000001 (für die erste farbe) 0b0100000000000 für die zweite usw
08:58:29 Schrompf: und du sortierst die vier bitsets (eins pro farbe) nach anzahl karten, also nach anzahl bits
08:59:24 Schrompf: dein kartenset ist also vollständig beschrieben durch 4x ähm... 13 bits?
08:59:27 Schrompf: 14?
08:59:35 Schrompf: 13
09:00:14 IceMichael: ja, so speicher ich zurzeit ne Hand bzw. zwei Hände + Flop eben
09:00:29 IceMichael: jedes gesetzte Bit entspricht einer Karte
09:00:33 Schrompf: genau
09:01:42 Schrompf: erstmal die einfache idee auf dieser basis: die wahrscheinlichkeiten, die sich am ende für eine bestimmte kombi ergeben, sind zwar irgendwelche rationalen zahlen, aber wahrscheinlich gibt's nur ein paar dutzend unterschiedliche werte
09:02:20 Schrompf: du könntest also alle möglichen zahlenwerte der wahrscheinlichkeiten in ne tabelle ziehen und dann nur den tabellenindex speichern, das geht dann wahrscheinlich in 5, 6 bits (anstatt in 32bits für nen float)
09:02:29 Schrompf: ne klassische palette
09:03:24 Schrompf: und davon unabhängig die komplizierte idee
09:03:52 Schrompf: anstatt mit nem 52bits-Key in die tabelle zu gucken, könnte man den key drastisch reduzieren
09:04:09 IceMichael: also ich muss mir an Ausgängen merken, wie oft man gewinnt, splittet und verliert/sample
09:04:23 IceMichael: und diese drei Zahlen sind bis zu vierstellig
09:04:31 Schrompf: das ist schon wieder ein satz, der wahrscheinlich nur für pokerspieler einen sinn ergibt
09:04:43 IceMichael: na ja, ich kann gewinenn, verlieren und unentschieden haben?
09:05:06 IceMichael: "splitten" heißt es nur, weil dann das Geld gleichmäßig aufgeteilt wird, aber ist einfach unentschieden, was es ja in sehr vielen Spielen gibt
09:05:25 Schrompf: gut
09:05:39 Schrompf: aber selbst vierstellig wären nur 13 bits oder so. immer noch ein drittel von nem float
09:06:05 IceMichael: ja, ich nutze keinen 52bit key, ich hab ja schon gesagt, meine LUT ist in der Hinsicht minimal
09:06:18 Schrompf: und ich behaupte, dass es immer wiederkehrende zahlen gibt, dass das kein linearer range ist, sondern einige typische zahlenwerte
09:06:39 Schrompf: wie sieht denn dein key gerade aus?
09:07:17 IceMichael: also ich habe ja 7 Farben, die ich mir anschauen muss (die Werte sind egal, weil ich pro Wert eh ne eigene LUT bauen muss)
09:07:35 Schrompf: 7 farben?
09:07:40 Schrompf: gibt doch maximal vier
09:07:42 IceMichael: sorry, 7 Farbwerte
09:07:47 IceMichael: Farben für 7 karten
09:08:01 IceMichael: Spieler1-Hand, Spieler2-Hand, drei Karten in der Mitte
09:08:03 Schrompf: ok. und nicht auch die werte der karten
09:08:16 IceMichael: nee, weil ich pro Wert von Karten ne eigene Tabelle hab
09:08:33 IceMichael: ich hab nachher sehr viel Tabellen, ich gruppiere nicht wert-übergreifend, weil das nochmal ne ganz andere Problemkomplexität hätte
09:08:52 IceMichael: somit sind das hier nur 4^7 Einträge
09:09:03 IceMichael: unkomprimiert
09:09:15 IceMichael: aber sollte eben einen schnellen Lookup möglich machen
09:09:25 IceMichael: ok, aber du hast jetzt ne Idee, wie ich die 4^7 Einträge auf weniger kriege?
09:09:42 IceMichael: ach sorry, ich red Müll hier
09:09:44 Schrompf: naja... weiß nicht. das problem ist erstmal anders, als ich verstnaden habe
09:10:05 IceMichael: 4^7 sind ALLE Einträge, aber eben die kann ich durch meine Pattern ja auf 5% reduzieren etwa
09:10:15 Schrompf: 4⁷ sind jedenfalls nüscht. 16k. das kannst du linear in ein array hauen und es passt noch in den first level cache
09:10:18 IceMichael: ich hätte jetzt also ne LUT gebaut mit 4^7 * 0,05 Einträgen
09:10:56 IceMichael: ja, aber wenn ich ALLES LUTen will (einfach um nix mehr berechnen zu müssen live), müsste ich sehr viele der LUTs bauen
09:11:15 IceMichael: und daher sind die 4^7 * 0,05 immer noch Faktor 10 zu viel
09:11:59 IceMichael: also sorry, noch ein falsches Detail:
09:12:04 IceMichael: Werte von Hand1 / Hand2 sind fixiert
09:12:10 IceMichael: aber die drei in der Mitte nicht, da geh ich ALLES durch
09:13:03 IceMichael: also z.B. AK vs QJ (Ass-König, Dame-Bube, das ist fixiert) für ALLE möglichen Karten in der Mitte wie 987, AK2, ... kann ich gerade dadurch optimieren
09:13:17 Schrompf: da kommt jetzt ne menge poker-gedöns rein, das ist mir ehrlich zu kompliziert
09:13:29 IceMichael: Ass ist Pokergedöns? oder was meinst du?
09:13:38 IceMichael: es gibt zwei Spieler, jeder hat zwei Karten auf der Hand
09:13:58 IceMichael: das ist aber eigentlich alles total egal fürs Problem
09:14:19 IceMichael: wichtig ist nur: Es gibt 7 Karten insgesamt und für die Konstellation hab ich ne Gewinnwahrscheinlichkeit
09:14:25 Schrompf: ich überlege aber gerade: die spielerin hat ja maximal zwei karten aus 52 möglichen. du könntest also für 52*51 möglichkeiten vorab die wahrscheinlichkeiten ausrechnen und wärst fertig
09:15:06 Schrompf: und die optionen könntest du noch reduzieren durch deine farbhäufigkeitssortierung
09:15:20 IceMichael: es sind schon alle 7 Karten wichtig
09:15:31 Schrompf: nö. die vom gegner kennst du doch nicht
09:15:37 Schrompf: da musst du von allen möglichen ausgehen
09:15:38 IceMichael: doch, man grenzt das ein
09:16:00 IceMichael: da kommt Kontextwissen dazu, womit ich dich mal verschonen möchte, aber der User sagt: Der Spieler hat 80% aller Karten z.B.
09:16:10 IceMichael: also er kann 80% aller möglichen Karten halten, 20% kann man aus Gründen ausschließen
09:16:30 Schrompf: das verstehe ich. aber du kannst du am ende die optionen runterbrechen
09:16:38 Schrompf: wir haben zwei sichtbare karten
09:16:45 Schrompf: auf der hand der spielerin
09:16:58 Schrompf: jetzt nehmen wir eine karte dazu. es ist egal, welchen konkreten wert die karte hat
09:17:00 IceMichael: man gibt auch der Spielerin so was wie 50% statt einer Hand
09:17:27 Schrompf: wichtig sind nur die fallunterscheidungen: gleiche farbe oder andere farbe? und zahlenwert höher/gleich/niedriger
09:17:44 Schrompf: vielleicht mit erweiterung "eins höher" / "mehrere höher", um straßen abbilden zu können
09:17:50 IceMichael: hm, was willst du mit der Fallunterscheidung machen?
09:18:04 IceMichael: ein Regelwerk dazu, wer gewinnt, kriegst du damit nicht hin
09:18:26 Schrompf: einen baum aufbauen. du hast 52x51 optionen, aber mit jeder karte, die du betrachtest, kommen jetzt nur ein paar bit an zusätzlichen informationen dazu
09:18:56 IceMichael: ich versteh die Idee, aber das klappt bei Poker nicht, wurd schon vielfach untersucht
09:19:07 IceMichael: der Baum ist viel komplexer und schwieriger zu finden als es einfach hochoptimiert durchzurechnen
09:19:13 Schrompf: du könntest also pro startkombi einen baum aufbauen, der sich entlang der möglichkeiten hangelt
09:19:38 Schrompf: und die möglichkeiten sind nicht groß
09:19:45 IceMichael: glaub es mir, das geht nicht
09:19:59 Schrompf: hm. ok. mir sieht's gerade überschaubar aus
09:20:12 IceMichael: also Spieler1 hat ne fixierte Hand und Spieler 2 auch?
09:20:40 IceMichael: also es gibt in der Mitte (für beide Spieler) drei Karten. Man kombiniert die eigene Hand mit den drei Karten, selbiges kann der Gegner tun
09:20:50 IceMichael: Hand = zwei Karten auf der Hand
09:20:53 Schrompf: nein. spieler 2 ist unbekannt, da braucht man gar nicht konkrete werte, sondern du willst du eh nur die anzahl kombis haben, gegen die die spielerin gewinnt
09:21:18 IceMichael: unbekannt heitß ja, du musst alle Möglichkeiten durchgehen
09:21:39 Schrompf: ja, aber offline :-) und im spiel hast du dann nen baum
09:21:41 Schrompf: warte mal bitte
09:21:45 Schrompf: lass mich mal reden
09:21:51 IceMichael: okay
09:22:21 Schrompf: dumpfe ausgangslage: spielerin hat zwei karten, erstmal plump 52*51 möglichkeiten. da kann man schon was rausholen, aber erstmal egal
09:22:42 Schrompf: jetzt baust du offline, also vorab, ne map für jede dieser möglichkeiten
09:24:08 Schrompf: du stellst dich auf eine dieser 2500 optionen. ich nehm jetzt mal piek-10 und rot-drei
09:24:43 Schrompf: jetzt nehme ich in meiner berechnung die erste neue karte hinzu
09:24:55 Schrompf: dann kann das zwar eine von fünfzig sein
09:25:02 Schrompf: aber welche genau das ist, ist mir egal.
09:25:19 Schrompf: ich kann offline jede durchrechnen, dann macht es das übelst aufwändig, aber mir ist das egal, weil offline
09:25:34 IceMichael: ok, aber eine Zwischenfrage, sonst macht das nicht so viel Sinn. Was heißt "ne Karte dazu nehmen?"
09:25:46 IceMichael: der Spieler hat 2 Karten und kriegt auch kein emehr
09:26:09 Schrompf: ich baue schrittweise eine spielsituation auf, indem ich z.b. die erste karte des flops hinzurechne
09:26:26 Schrompf: das ist kein spielmove, sondern ein algorithmus
09:26:27 IceMichael: ah ok, macht Sinn!
09:26:40 IceMichael: hätte ja auch von Spieler2 sein können statt Flop, daher die Frage, aber ok, gern weiter
09:27:05 Schrompf: ich nehme jetzt also ne dritte karte in die betrachtung. das kann eine von 50 sein, aber konkret gibt es nur die folgenden optionen:
09:27:22 Schrompf: - piek, größer als bube
09:27:33 Schrompf: - piek, bube (für straße)
09:27:40 Schrompf: - pike, 9 (für straße)
09:27:47 Schrompf: - piek, kleiner als 9
09:28:01 Schrompf: - rot, höher als 4
09:28:03 Schrompf: - usw
09:28:50 Schrompf: ob es rot dann ein bube oder ne 8 ist, ist mir ja wurscht. entscheidend ist nur die anzahl optionen, die mit dieser rotkarte zu nem zweier führen, der höher als die rote drei ist, mit der *ich* nen zweier bilden könnte
09:29:54 Schrompf: ich kann also alle roten karten höher als vier in eine möglichkeit gruppieren, und die haben alle die selben outcomes, weil "höher als Paar Dreien" reicht
09:30:47 Schrompf: und damit hast du durch das hinzunehmen einer karte in die spielsituation nur ein paar dutzend neue spielsituationen, die du vorab komplett ausrechnest
09:31:43 Schrompf: und jetzt kannst du von jeder dieser spielsitationen die nächste karte in die betrachtung reinnehmen. dadurch ergeben sich jetzt mehr möglichkeiten, jenachdem welche karte du hinzunimmst
09:32:00 IceMichael: also du willst für eine große Menge an Karten neue Situationen aufbauen=?
09:32:16 Schrompf: naja... ja
09:32:32 IceMichael: ich mein, jede rote Karte gibt die Chance, dass der Spieler später trotzdem einen Flush macht (5 gleiche)
09:32:50 IceMichael: und selbst wenn der Spieler so was kriegt, erhält der Gegner potentiell Gegenchancen
09:33:31 Schrompf: jupp, aber in der baum-idee ist dir das ja wurscht, weil du beim hinzunehmen doch weißt, dass jetzt in deiner aktuell betrachteten spielsituation weniger rest-rotkarten drin sind
09:33:32 IceMichael: auch die 8 kann später zur Straße verhelfen, ne 7 auch, ne 6 auch, es gibt ja später insgesamt 5 Karten in der Mitte
09:33:39 Schrompf: ja, alles richtig.
09:33:50 Schrompf: ahso
09:33:51 Schrompf: ja
09:33:51 IceMichael: na ja, 11 statt 12 Restrotkarten, wieso nützt das?
09:34:21 Schrompf: weil's die wahrscheinlichkeiten verändert, welche karten du in den hypothetischen spielsituationen betrachten musst
09:34:29 Schrompf: ich komm nochmal rein
09:34:42 Schrompf: das komplette universum aller pokerspiele
09:34:52 IceMichael: also wenn es nicht 50 verschiedene Situationen sind (und das wäre ja einfach eh das Maximum, wo mir der Regelbaum nix mehr bringt), dann sind es vermutlich zumindest mal 30
09:35:16 IceMichael: aber die Grundannahme, dass Spieler2 ne zufällige Hand, ist leider nicht nützlich
09:35:39 Schrompf: ist 52 * 51 (spielerhand) * 50 * 49 * 48 (der flop) * 47 * 46 (gegnerhand)
09:36:01 Schrompf: man kann hier mit deiner farbsortieridee schon einiges rausholen, aber die anzahl optionen ist erstmal GIGANTISCH
09:36:16 IceMichael: ja, du kannst sogar 52*51/2 teilen, weil die Reihenfolge egal ist
09:36:31 Schrompf: ich formuliere es jetzt erstmal schlicht, bitte nicht hauen
09:36:33 IceMichael: man hat 52*51/2 * 50*49*48/3/2 * 47*46/2
09:36:57 Schrompf: du baust jetzt ausgehend von 52*51/2 startmöglichkeiten einen baum auf
09:37:00 IceMichael: also 28 Mrd. Ausgangssituationen (in einer Situation ist natürlich noch nicht klar, wer gewinnt)
09:37:12 Schrompf: du hast also 52*51/2 startknoten
09:37:16 Schrompf: 1200
09:38:00 Schrompf: wir fangen im kopf jetzt mal eine dieser situationen an, z.b. die oben genannte hand von piek-10 und rot-3
09:38:51 Schrompf: jetzt hast du hier *schlimmstenfalls* 50*49*48/3/2 * 47*46/2 subknoten
09:39:21 IceMichael: ja
09:39:34 Schrompf: und in unserem strunzdummen beispielprogramm ohne jede optimierung rechnen wir jetzt jede option durch
09:40:09 Schrompf: wir können also ne strichliste führen, wieviele dieser unter-situationen in einem gewinn für die spielerin resultieren, wieviele split und wieviele verloren
09:40:57 Schrompf: aber wir bauen diese spielsituationen wieder als subknoten auf
09:41:27 Schrompf: und für jeden subknoten gibt es wieder deutlich weniger möglichkeiten
09:42:16 Schrompf: und wir können mit z.b. deiner farbsortierungsidee oder mit meiner "gleich, größer, kleiner"-idee (die möglich nicht funktioniert, kann ein) die anzahl subknoten weiter reduzieren
09:43:15 Schrompf: aber das können wir notfalls auch nachher machen, indem wir wirklich von hand hardcore jede option der 28 milliarden ausrechnen, in so nem baum gruppieren und erst danach gemeinsamkeiten zusammenfassen
09:43:29 Schrompf: das ergebnis dieser übelsten offline-berechnung soll jedenfalls ein baum sein
09:44:04 Schrompf: die einzelne spielsituation ganz am ende der 52*51/2 subknoten ist Gewonne/Split/Verloren
09:44:47 Schrompf: der erste Knoten vor der einzelnen Spielsituation ist also eine Summe Outcomes über alle Subknoten
09:45:17 Schrompf: und so baust du rückwärts von den einzelnen Ergebnis-Spielsituationen einen Baum auf, welcher Teilzweig wie oft zu Gewinnen / Split / Verloren führt
09:45:22 IceMichael: also ja, ich verstehe, was du meinst und ich mag das
09:45:28 IceMichael: ich hab darüber auch kürzlich nachgedacht
09:45:36 Schrompf: 28 Milliarden Optionen sind halt ein fieses Brett
09:45:41 IceMichael: das Problem war daran, dass diesen Baum "effizient" aufzubauen, also Regeln zu finden, extrem komplex war
09:45:45 IceMichael: und meine Versuche haben zu nichts geführt
09:45:53 Schrompf: und ob diese Idee funktioniert, hängt sehr davon ab, ob du zusammenfassen kannst
09:46:04 Schrompf: da finde ich deine idee der farbsortierung schon sehr gut
09:46:13 IceMichael: ja, das ist der Punkt:
09:46:18 Schrompf: und ich denke, du kannst auch die zahlenwerte gruppieren
09:46:31 IceMichael: ich hab rausgefunden, dass AK vs QJ für alle möglichen Flops zu 1100 Buckets von Equitiys zusammengefasst werden können
09:46:38 IceMichael: Theoretisch ist der Baum also megagut
09:46:47 Schrompf: du musst gar keine einzelwerte betrachten, sondern kannst es mit stochastischen mitteln erschlagen
09:46:53 IceMichael: aber Regeln zu finden, die funktionieren, ist extrem komplex
09:46:58 Schrompf: ja, moment
09:47:05 Schrompf: wie gesagt: eine hast du schon mit deinen farben
09:47:12 Schrompf: und eine will ich dir gerade vorschlagen
09:47:17 IceMichael: ah ok :)
09:47:26 Schrompf: ah shit, ich muss reden. 10min
09:49:37 IceMichael: kein Thema, ist ja kein Stress
10:12:25 Schrompf: nuja
10:13:10 Schrompf: die andere idee war, dass du bei der evaluierung aller subknoten nur die relevanten ranges betrachtest
10:13:34 IceMichael: hm, was ist relevant?
10:18:37 Schrompf: naja: gleiche farbe wie eine karte, die bereits in der vorauswahl ist, höherer wert, niedrigerer wert
10:19:19 Schrompf: oder "andere farbe, gleicher wert wie eine der karten in diesem teilbaum"
10:20:14 Schrompf: ob es dann ne 10 oder ein bube ist, kann dir (erstmal) egal sein, weil beides im falle von paaren, dreiern oder so ein "gewinnen" verursacht
10:20:48 Schrompf: du müsstest quasi dann ne abstrakte fallunterscheidung machen, wenn du von so einem range aus weiter reinrekursierst
10:21:47 IceMichael: das hängt aber von so vielen Sonderfällen ab...
10:21:54 Schrompf: du hast dann nicht mehr "auch ne fünf, aber von ner anderen farbe", sondern "der selbe wert wie die karte aus dem vorherigen subrange"
10:22:33 Schrompf: ja, das wird dann ein binary search, der nicht mehr binary ist :-)
10:22:47 IceMichael: ja, einfache Regeln gehen alle nicht, das hab ich probiuert
10:23:02 Schrompf: wenn du ne dritte karte hinzunimmst, kann dir höher/gleich/tiefer als K1 und unabhängig davon höher/gleich/tiefer k2 sein
10:23:25 Schrompf: aber du weißt in jedem fall, wieviele es davon gibt, und kannst die anzahl gewinnen/verlieren/split daraus ausrechnen
10:23:47 Schrompf: weil du bis zu diesem knoten in dem baum halt festgelegt hast, welche karten in der spielsituation bisher drin sind
10:24:09 IceMichael: aber das steht und fällt doch komplett damit, dass die Regeln auch "gut" sind, oder?
10:24:17 IceMichael: sonst hab ich alle Spielsituationen einfach nur ver-baum-t und sonst nichts gewonnen
10:24:29 IceMichael: und deine Regeln sind für sich genommen leider alle nicht gut, sorry :/
10:24:39 IceMichael: man kann so gut wie nix pauschalisieren auf die Weise
10:24:40 Schrompf: richtig. die dumme option, den kompletten baum aufzubauen, hast du immer. der wird nur evtl. ne weile rechnen
10:24:48 IceMichael: ja und er ist zu groß
10:24:50 Schrompf: hö? doch, klar, kann man
10:25:05 Schrompf: ich seh da locker 1:5 für jede einzelne farbe
10:25:27 IceMichael: also "Karte ist kleiner als" und "Karte als größer als" ist praktisch einfach nutzlos, sorry
10:25:35 IceMichael: das wurd schon ausprobiert
10:25:38 IceMichael: nicht nur von mir
10:25:51 Schrompf: nö, es ist bei Paar/Dreier/Vierer doch das einzige Kriterium?
10:26:12 IceMichael: aber es können doch später noch Karten kommen, die trotzdem Paare/Dreier/Vierer/Fullhouse erlauben
10:26:21 IceMichael: wir können damit nichts aus- oder einschließen
10:26:35 IceMichael: und selbst wenn müssen wir das immer mit Blick auf den Gegner machen
10:26:52 Schrompf: doch, kannst du, weil du in den tieferen subknoten dann durch das hinzuwählen einer weiteren betrachteten karte genau diese optionen entdecken und beziffern kannst
10:27:32 Schrompf: ob du "die gleiche karte, nur in rot" jetzt zuerst entdeckst oder erst weiter drin, kann dir doch wurscht sein. summanden kann man vertauschen, gleichheitsoperanden auch
10:28:11 IceMichael: ok, ich sehe, dass ich am Ende des Baumes dann evtl. manchmal 5 Karten zusammenfassen kann statt einer
10:28:14 IceMichael: das wäre /5
10:28:22 Schrompf: nein, du kannst es bei jedem teilschritt
10:28:24 IceMichael: aber durch den Baum habe ich ja auch den Overhead, dass ich die ganzen Regeln speichern muss
10:28:35 Schrompf: musst du auch nicht
10:28:42 Schrompf: die regeln stehen fest, das ist dein algorithmus
10:28:54 Schrompf: ahso, moment
10:29:05 Schrompf: du willst auch noch "12% chance auf nen dreier" mit ausrechnen oder sowas?
10:29:13 IceMichael: ne
10:29:24 IceMichael: ich will wissen, wie oft ein Spieler gewinnt
10:29:30 Schrompf: naja, und das kriegst du
10:29:54 IceMichael: aber ne Karte kommt dazu und ich hab den Fall, dass sie größer ist als beide meiner Karten auf der Hand, sagen wir mal?
10:30:12 IceMichael: jetzt hab ich die Möglichkeiten in "ja" und "nein" aufgesplittet, aber doch nicht reduziert. In der nächsten Baumstufe teile ich wieder auf
10:31:16 Schrompf: genau. und dort wird's dann mühsamer, aber immer noch gruppierbar
10:32:23 Schrompf: du hast beim hinzunehmen der vierten karte dann halt konkrete optionen "auch ne 10 wie K1" und abstrakte optionen "gleicher wert wie K3, von der ich nur weiß, dass sie höher als ne 10 ist"
10:32:41 Hannes joined the channel
10:32:49 Hannes: Ahoi und
10:32:57 Schrompf: Servus
10:33:03 Hannes: wenn ich das richtig mitbekommen habe:
10:33:10 Hannes: 🎂 für Schrompf
10:33:15 Schrompf: <3
10:33:15 Hannes: Happy Birthday
10:33:25 xq: achjo
10:33:27 xq: stimmt ja!
10:33:29 Schrompf: HexChat rendert die torte sogar richtig. Danke!
10:33:32 xq: Alle Güter zum Geburtstag!
10:33:44 IceMichael: AHHHH
10:33:44 Schrompf: vorhin ist auch gerade mein zockerstuhl gekommen
10:33:47 IceMichael: Verdammt
10:33:50 IceMichael: Herzlichen Glückwunsch!!
10:34:03 Schrompf: ich bin 42. da legt man nicht mehr so viel wert auf diesen tag
10:34:14 Schrompf: also danke danke und so, aber lasst mal gut sein
10:34:36 Schrompf: mein aktueller bürostuhl hat nämlich schon ein paar mal metallisch KRINK gemacht
10:35:08 Schrompf: und seitdem kann ich die sitzfläche nicht mehr neigen und die lehne versucht mit ganzer macht ihrer federkraft, mich die ganze zeit vom stuhl zu schieben
10:35:16 Schrompf: also hab ich mir einen neuen stuhl bestellt
10:35:27 Schrompf: und aus ner furzidee heraus ist es ein schwarzblauer gamer-stuhl
10:36:44 IceMichael: und der kann was?
10:37:37 IceMichael: also zu deiner Idee oben: ja, wenn man sehr viel Mühe und Zeit investiert und drölf Algos draufwirft, die irgendwie schlau Regeln finden, lässt sich damit sicherlich was machen. Aber ich seh leider nichts Triviales zurzeit :/
10:37:39 Schrompf: nuja, auch wippen, kippen, flippen. denke ich jedenfalls. vor allem aber ist er nicht kaputt
10:38:11 IceMichael: das ist doch was
10:38:28 Schrompf: zu meiner idee: ich denke, am anfang isses noch ganz einfach, aber spätestens bei der sechsten karte hast du schon ne fiese menge möglichkeiten. sind halt aber immer noch drastisch weniger als die 47, die in der echten auswahl drin sind
10:39:15 Schrompf: genau genommen musst du aber ab der sechsten karte keine teilbäume mehr speichern, da reichen dir ja die summierten outcomes
10:39:59 Schrompf: du willst ja vor allem erstmal die summe aller teilbäume haben, und sobald die erste karte des flops liegt, willst du in den teilbaum absteigen, der den sichtbaren informationen entspricht, um eine präzisierte outcome-vorhersage zu kriegen
10:40:22 Schrompf: und das finde ich halt das geile an dieser baum-idee. dass du genauer werden kannst, wenn du mehr weißt
10:40:43 IceMichael: ja, das ist auch nice
10:40:53 Schrompf: aber ich stimme dir im Groben auf jeden fall zu: es hängt davon ab, wie weit man die schiere anzahl möglichkeiten eingedampft kriegt
10:40:55 IceMichael: nur das Aufbauen vom Baum mit schlauen Regeln... ziemlich wild
10:41:14 IceMichael: ja, du hast ja auch recht, dass wohl selbst "schlechte" Regeln immerhin ein bisschen bringen
10:41:31 Schrompf: du kannst ja mal ausrechnen, wieviele optionen es sind, wenn man die sechste und siebte karte nie einzeln braucht, sondern eh ab der fünften nur noch die summen betrachtet
10:41:53 IceMichael: aber selbst das programmierte Regelwerk (klar, ist autogenerierter Code) wäre halt schon echt komplex
10:42:12 Schrompf: dann ist das ausrechnen dieser tabelle offline astronomisch lange, aber dein baum hat dann wohl nur noch ein paar dutzend millionen einträge
10:42:25 IceMichael: dann explodiert wiederum meine compiletime
10:42:37 Schrompf: hä?
10:42:41 Schrompf: jetzt wird's bunt
10:42:43 Schrompf: ich rede von nem heap
10:42:51 Schrompf: sowas wie std::make_heap() ausspuckt
10:42:52 IceMichael: du willst die Fallunterscheidungen/Regeln ja in den Baum packen
10:42:57 Schrompf: nö
10:43:05 IceMichael: äh, als Algo implementieren, also im Code haben
10:43:22 IceMichael: da wenige Regeln nix bringen, werden es viele sein, also viel Code?
10:43:28 Schrompf: ich will die fallunterscheidungen / regeln bei der ausrechnung des kompletten baums offline ausnutzen, um die anzahl optionen kleiner zu kriegen
10:43:46 Schrompf: aber im code und in den daten stehen nachher nur noch reine kartenkombis
10:44:30 IceMichael: hm ja. Das Auswerten von Regeln und Absteigen im Baum kostet halt auch wieder Zeit. D.h. die Reduktion muss schon so viel bringen, dass es mir hilft
10:44:42 Schrompf: und wir reden hier von schlimmstenfalls vielleicht einigen hundert zeilen code. einmal std::vector<> mit nem neuen Typen instanziieren verursacht das zehnfache
10:45:47 Schrompf: das iterieren durch den baum sind auch nur mikrosekunden schlimmstenfalls. du bist in nem teilbaum, du nimmst ne neue karte hinzu, deren index innerhalb dieses knotens musst du ausrechnen, dann kannst du direkt in den subknoten uplooken
10:46:16 Schrompf: die diversen zusammenfass-ideen machen den index kleiner, aber wie gesagt: ein paar taktische if(), mehr nicht
10:46:55 IceMichael: aber ich muss für jeden Teilbaum für jede Karte, die kommen kann, die Indizes speichern
10:47:17 Schrompf: nein, der index ist implizit in der baumstruktur, so wie halt bei jedem baum
10:47:22 Schrompf: ich mal mal was
10:47:35 IceMichael: ja, aber sagen wir, bei Karte 1 gibt es jetzt 20 Möglichkeiten
10:47:43 IceMichael: für jede dieser 20 Möglichkeiten gibt es doch wieder 20 neue usw.
10:47:49 IceMichael: also mein 20^x behalt ich hier doch
10:48:07 Schrompf: nö, das baust du iterativ auf, während du durch den baum marschierst
10:48:17 IceMichael: aber beim Lesen muss ich ja die Regeln abrufen?
10:48:27 IceMichael: und die müssen irgendwo gespeichert sein
10:49:08 Schrompf: nein, die regeln sind im code, die hast du kompiliert. was willst du da denn speichern oder abrufen?
10:49:18 IceMichael: also ich bin recht sicher, dass ich nur auf dem letzten Level überhaupt ein paar Karten zusammenfassen kann, dass die letzte Karte nicht entscheidend ist, ist superselten
10:49:30 Schrompf: moment, ich mal was
10:49:36 IceMichael: ja okay, das hilft vermutlich
10:49:44 IceMichael: ist wieder dieses Problem, dass wir nicht zusammen an einem Whiteboard drüber reden :)
10:50:37 IceMichael: zudem bin ich durch den 3. Tag in Folge von 6.30 bis 9.00 Uhr Arbeitsbeginn an dieser Problematik unter Stress arbeiten gefolgt von 8h normaler Arbeit und noch ner Abendsession im Hirn auch schon etwas grütze und übermüdet, daher steh ich gerade leicht auf dem Schlauch
10:50:59 IceMichael: v.a. alles mit drölf Kontextwechseln immer, kotzwürg
10:51:32 Schrompf: ist halt auch schwierig übr text. und vielleicht überseh ich wirklich was
10:51:42 Schrompf: eigentlich müsste ich auch mal was arbeiten :-(
10:51:45 Schrompf: nuja, erstmal hier
11:09:50 Schrompf: https://aggie.io/r7xujsk2lx
11:09:55 Schrompf: siehste was?
11:09:59 Schrompf: läd ne weile
11:10:48 IceMichael: klick
11:11:03 IceMichael: ja, ich seh was
11:11:07 IceMichael: interessante seite
11:11:15 Schrompf: fix ergoogelt
11:11:43 Schrompf: was ich damit sagen will: du nimmst ne karte zur spielsituation dazu
11:12:02 Schrompf: deren wert ist nur relevant im vergleich zu den bisherigen werten
11:12:14 Schrompf: deren farbe ist nur relevant im vergleich zu den bisherigen farben
11:12:21 Schrompf: (das hast du ja bei dir schon umgesetzt)
11:12:49 Schrompf: es gibt also die optionen "gleiche farbe wie K1", "gleiche Farbe wie K2" und "neue Farbe"
11:13:14 Schrompf: multipliziert mit den optionen "höher als K1", "genau wie K1", "zwischen K1 und K2", "genau wie K2" und "kleiner als K2"
11:13:51 Schrompf: mit ein bissl index-magie könntest du die beiden unmöglichen optionen "gleiche farbe und gleicher wert wie Kx" auch noch rausrechnen, aber es macht keinen großen unterschied und so ist es simpler
11:14:26 Schrompf: und das lässt sich jetzt fortsetzen
11:15:14 Schrompf: mir fällt gerade auf, so ne substitution wie bei den farben würde hier auch helfen
11:15:22 Schrompf: du rechnest nicht mehr mit konkreten kartenwerten
11:15:30 Schrompf: sondern nur noch mit abstrakten werthöhen.
11:15:42 Schrompf: die du außerdem der größe nach sortierst, so wie bei den farben
11:15:55 IceMichael: ok, also ich glaube/hoffe, ich hab das schon kapiert
11:16:02 Schrompf: dann haben deine zwei startkarten W1 und W2
11:16:34 Schrompf: und die neu hinzugenommene Karte kann WmehrAls1, W1, Wzwischen1und2, W2 und "WkleinerAls2" haben
11:16:53 IceMichael: ok, es hat relativen Bezug
11:16:57 Schrompf: nur dass die zwischen-werte potentiell mehr als einen konkreten wert enthalten
11:17:01 IceMichael: daher nicht viel speichern oder superviele ifs
11:17:08 Schrompf: genau
11:17:18 IceMichael: aber am Ende des Baumes, in den Blättern, muss ich ja natürlich trotzdem was speichern
11:17:24 Schrompf: und außerdem perfekt enumerierbar und deswegen direkt als index in ein array aus subknoten nutzbar
11:17:40 Schrompf: daher brauchst du in den subknoten nie den index speichern, der dahin geführt hat
11:18:06 Schrompf: denn den hast du bereits aufm weg dahin benutzt und aus dem ergibt sie die spielsituation vollständig
11:18:37 IceMichael: ok, also am Ende hab ich jeweils etwas speicher-lineares (array, whatever)
11:18:47 IceMichael: aber davon hab ich viele, die nicht direkt im Speicher hintereinander liegen, weil Baum
11:18:59 IceMichael: was vermutlich eh egal ist
11:19:01 Schrompf: die kannst du auch als riesiges array speichern, so macht das std::make_heap
11:19:09 IceMichael: gut, ja
11:19:12 Schrompf: aber es ist nur ein implementationsdetail
11:19:42 IceMichael: denkst du denn, das bringt auch dann was, wenn ich immer bis zur letzten Karte absteigen muss bzw. für die letzte Karte evtl. 5 oder so zusammenfassen kann?
11:19:45 Schrompf: am ende hast du ne struct Node { Karte k1, k2; vector
11:20:03 Schrompf: du fasst ja bereits in der ersten hier skizzierten stufe zusammen
11:20:25 Schrompf: du musst in jede der fünfzehn hier skizzierten subknoten nur einmal absteigen
11:20:25 IceMichael: hmmm
11:20:46 IceMichael: ok, aber das setzt doch dann voraus, dass ich mit >9 karo auch irgendeine Gruppierung haben kann, oder?
11:20:53 IceMichael: also wenn das ne Zusammenfassung ist, dann ist ja karo 9 wie karo 10?
11:21:04 IceMichael: äh, oder da steht > und nicht >=, wie auch immer
11:21:06 Schrompf: sicher. wenn der gegner ne >9 piek und ne >9 herz hat, hat er gewonnen
11:21:17 IceMichael: ne, noch lange nicht, gibt immer KOntermöglichkeiten später
11:21:34 Schrompf: nein, das geben die spielregeln nicht her
11:21:53 IceMichael: sorry, schreib mal bitte kurz Hand Spieler1, Hand Spieler2 und Flop auf, für den du das meinst
11:22:01 Schrompf: du müsstest halt ne bessere kombo haben. aber auch die hat dann später halt ne >9 als wert, das ist dir in diesem schritt egal
11:22:24 IceMichael: als ein einfaches Beispiel
11:22:41 IceMichael: also wo du denkst, dass karo 9 und karo 10 also Karte auf dem Flop gleich wäre
11:22:51 Schrompf: nene, das hast du erfunden
11:22:57 Schrompf: es gibt einen unterschied zwischen 9 und >9
11:22:58 IceMichael: ne, du hast gesagt, die Regeln geben das nicht her
11:23:13 Schrompf: aber es gibt keinen unterschied, ob die >9 jetzt ne dame oder ein könig ist
11:23:20 IceMichael: woher weißt du das?
11:23:33 Schrompf: hä? das siehst du doch
11:23:41 IceMichael: ich sehe, das dein Beispielbaum so ist
11:23:48 IceMichael: aber das ist nicht das, was in Poker passiert
11:24:06 Schrompf: wir sind hier beim ersten Teilschritt beim Absteigen
11:24:13 Schrompf: es kommen doch noch weitere Absteigeschritte
11:24:24 Schrompf: und in denen differenziert sich dann vielleicht aus, ob das ne Dame oder ein König ist
11:24:35 Schrompf: aber doch nur, wenn wir in diesem Schritt überhaupt in die >9-Zweige absteigen
11:24:51 IceMichael: ja und wir müssen immer dann absteigen, wenn die Gewinnchance eben anders dafür ist
11:25:03 Schrompf: nein
11:25:39 IceMichael: also ich meine, wenn >9 karo definieren würde, dass weitere Details nutzlos sind, wären wir doch am Ziel?
11:26:19 Schrompf: nein, die details kommen erst beim absteigen. und beim nächsten schritt machst du doch wieder den teilbaum auf, da kann wieder ne dame oder ein könig hinzukommen
11:26:24 Schrompf: es ist nur in diesem teilschritt egal
11:26:34 IceMichael: ja, ok, das kapier ich ja auch
11:26:58 Schrompf: du hast hier - zwei karten sichtbar, du betrachtest die erste karte des flops - diese fünfzehn optionen. zwei davon ungültig
11:27:00 IceMichael: ich glaube nur, wir bauen im Endeffekt einen riesen Baum, aber wir kommen eh zu nichts, bevor wir nicht im letzten Teilschritt fast jede einzelne Karte auseinanderklamüsert haben
11:27:18 Schrompf: jede dieser fünfzehn subknoten ist eine eigene spielsituation, in der du jetzt drei karten gegeben hast
11:27:23 IceMichael: und wir haben hier nen Baum... also irgendeinen Overhead hat der ja ggü. einer einfachen Liste aller möglichen Ausgänge
11:27:54 Schrompf: ja, es wird ein baum. und wir sind gerade im offline-vorberechnungs-modus
11:28:24 IceMichael: ja, aber ist ja egal, die Struktur ist ja soweit fix oder ist das nur ne Beispielstruktur?
11:28:53 Schrompf: und da treiben wir dieses spiel bis zur 7. karte. in jedem der millionen teilbäume haben wir jetzt ein halbwegs konkretes set an 7 karten, deren outcome wir anhand der pokerregeln sehen
11:29:12 Schrompf: und jetzt rechnen wir zurück
11:29:35 Schrompf: wir haben nach dem aufstellen aller möglichen siebten karten für jede spielsituation das outcome ermittelt
11:29:48 IceMichael: okay, klar so weit (denk ich)
11:30:02 Schrompf: und rechnen jetzt für den teilbaum in der sechsten stufe da unten all diese outcomes zusammen. und speichern die im node
11:30:12 Schrompf: (bzw. nicht im 6., aber das ist egal)
11:30:24 IceMichael: hm, redundant zum 7. Level oder schmeißen wir das 7. dann raus?
11:30:37 Schrompf: redundant, im prinzip
11:31:02 IceMichael: ok, also erstmal mehr Speicherverbrauch als komplett alles zu speichern an dieser Stelle (nur zum Verständnis)
11:31:24 Schrompf: speicher ist an der stelle egal
11:31:27 IceMichael: gut
11:31:51 Schrompf: wir denken mal nur bis zur 5. stufe. da, wo die dritte karte des flops aufgedeckt wurde
11:32:30 IceMichael: ok
11:32:39 Schrompf: wenn wir an der stelle des spiels ausrechnen wollen, wie unsere chancen stehen, das zu gewinnen
11:32:54 Schrompf: denken wir uns jede mögliche sechste karte (die erste der gegnerin)
11:33:17 Schrompf: und von jeder möglichen 1. gegnerkarte jede mögliche zweite gegnerhandkarte
11:33:45 Schrompf: und haben jeweils sieben handkarten in der betrachtung, anhand derer wir das outcome sehen
11:33:59 IceMichael: ja, soweit also volle Enumeration wie ohne Baum
11:34:15 Schrompf: genau. nur dass du das für dieses fünferset an karten, die dazu geführt haben, speicherst
11:34:39 IceMichael: ok, also soweit die Idee einer vollen lookup table für alle Möglichkeiten
11:34:43 Schrompf: und wenn du das für alle fünfer gemacht hast, rechnest du zu jedem vierer die outcome-summen aller subzweige auf und speicherst die im vierer
11:34:53 Schrompf: genau
11:35:16 IceMichael: okay, also auf jedem level speicherst du Aggregate der unterlevels
11:35:18 Schrompf: und ich behaupte (und will anhand der zeichnung zeigen), dass du aufm weg dahin sachen zusammenfassen kannst
11:35:50 IceMichael: hm, den Teil versteh ich nicht
11:35:57 Schrompf: so dass dein precomputed lookup table dann aus vielleicht 20⁵ und nicht aus 52⁷ besteht
11:36:12 IceMichael: du fasst immer zusammen, wenn zwei benachbarte Zweige dieselben Aggregatwerte haben?
11:36:20 Schrompf: genau
11:36:26 Schrompf: der selbe trick wie bei deinen farben
11:36:28 IceMichael: ja, dann versteh ich die Theorie
11:36:40 IceMichael: aber das setzt ja nach wie vor voraus, dass so was wie ">9" wirklich dasselbe sein könnte wie "=9"
11:36:45 Schrompf: nein
11:36:46 IceMichael: nicht muss, aber könnte
11:36:50 Schrompf: nein
11:36:53 Schrompf: tut es nicht.
11:36:57 IceMichael: aber das sind zwei benachbarte Zweige
11:37:10 IceMichael: wenn die Chance 0 ist, dass die dieselben Aggregate haben, versteh ich's doch nicht
11:37:10 Schrompf: es betrachtet explizit absichtlich und mit anlauf diese beiden situationen in zwei verschiedenen zweigen
11:37:23 Schrompf: es fasst >9 und >9 zusammen
11:37:34 Schrompf: aber >9 und 9 sind doch zwei verschiedene hände, wenn die andere karte ne 9 ist
11:37:47 Schrompf: daraus ergeben sich doch nach pokerregeln andere blätter
11:38:18 IceMichael: ok, immer noch nicht klar für mich, was du zusammenfasst
11:38:27 IceMichael: ich hätte gedacht, benachbarte Zweige kann man mergen, wenn die eh dasselbe Ergebnis bringen
11:38:28 IceMichael: jetzt sagst du: ne
11:38:32 Schrompf: nein
11:38:48 Schrompf: das, was ich skizziert habe, ist bereits zusammengefasst
11:39:07 Schrompf: man kann dort die zweige "Rot König" und "Rot Zehn" zusammenfassen
11:39:14 IceMichael: ok, das heißt, es ist das Resultat davon, dass wir Zweige mit gleichen Ergebnissen angeschaut haben und daraus so was wie >9 generiert haben?
11:39:42 IceMichael: also "Zweige" = Karten, die erschienen sind
11:40:00 Schrompf: ja. wir haben in dem beispiel Karo9 und Rot4 auf der hand
11:40:09 Schrompf: und gucken jetzt die erste Karte des flops an
11:40:35 Schrompf: wenn die auch ne 9 ist, haben wir ein paar in unserem sichtbaren bereich. das ist ein eigener zweig, weil wir schonmal ein paar haben
11:40:51 Schrompf: da kann nie wieder "kein paar" draus werden, egal wieviele weitere karten wir nachziehen
11:40:55 IceMichael: okay, ich glaub, dann versteh ich es so langsam
11:41:17 IceMichael: die Methode fasst also dann zusammen, wenn es auf irgendeinem Level (ob unten oder, mit Glück oben) zwei Karten zu demselben Ergebnis führen
11:41:34 Schrompf: genau
11:41:49 IceMichael: hm... ja, müsste man einfach mal ausprobieren
11:42:07 Schrompf: und wir müssen hier gar nicht vorausplanen, ob hier nachher noch ein Dreier aus Damen rauskommen kann
11:42:08 IceMichael: aber ja, sorry für meine Langsamkeit, das ist natürlich sehr schlau :)
11:42:18 Schrompf: das müssen wir erst einplanen, wenn wir die erste dame gezogen haben
11:42:29 IceMichael: krass bin ich langsam im Kopf heute
11:42:57 Schrompf: und diese einteilung mit >9, 9, 8...5, 4, <4
11:43:00 Schrompf: das ist optional
11:43:15 Schrompf: du kannst auch jeden einzelnen teilzweig berechnen, full blown bruteforce
11:43:20 Schrompf: und nachher zusammenfassen
11:43:34 IceMichael: ja, das wäre wohl mein Ansatz, ist durchaus offline möglich
11:43:41 Schrompf: diese einteilung in wertebereiche ist nur ne verbesserung, um den zu betrachtenden baum schmaler zu kriegen
11:43:53 Schrompf: aber am ende müsste das selbe rauskommen
11:44:02 IceMichael: ja, aber möglicherweise mit Verlusten, weil man was zu stark vereinfacht hat
11:44:20 Schrompf: bruteforcen würde ich evtl. aber der fünften oder sechsten stufe, ehrlich. irgendwo da werden die merge-regeln dann beliebig kompliziert
11:44:37 Schrompf: nö, verluste gibt es da nicht, außer wir haben in unseren zusammenfass-regeln was übersehen
11:44:45 IceMichael: so was wie >9 karo... ist nicht
11:44:53 Schrompf: wieso?
11:45:37 IceMichael: puh, ok, also es soll nicht heißen, dass die Unterscheidung zwischen Karo Ass und Karo König hier egal ist?
11:45:46 Schrompf: hier ja, in der dritten stufe
11:46:12 Schrompf: du musst erst in der vierten stufe unterscheiden, falls in der dritten ein Karo Ass gekommen ist
11:46:18 IceMichael: ok, aber dann müssen wir ja ggf. ne Stufe mehr einbauen, um dieselbe Karte nochmal zu differenzieren
11:46:32 IceMichael: ggü der Chance, dass >9 karo evtl. ne gute Idee ist
11:46:33 Schrompf: und genau das musst du nicht, das ist das geniale an diesem ansatz
11:46:42 IceMichael: hä, moment
11:46:57 IceMichael: also entweder wir müssen später noch dazwischen unterscheiden, ob diese eine Karte jetzt halt genau ein Karo Ass oder Karo König ist
11:47:07 IceMichael: d.h. wir brauchen für diese eine Karte eben zwei Stufen (oder mehr)
11:47:16 IceMichael: oder wir sagen: uns ist bei dieser Karte egal, ob sie Karo Ass oder Karo König ist
11:47:17 Schrompf: du musst im zweig >9 karo gar nicht genau festlegen, dass das jetzt ne dame ist
11:47:35 IceMichael: aber im nächsten willst du es auch nicht prüfen, ob es könig oder dame ist? irgendwo müssen wir das doch
11:47:53 Schrompf: weil du in dem zweig dann nur noch die abstrakte unterscheidung "mehr als die fiktive karte karo >9" oder "gleicher wert" oder "kleiner als die fiktive karte karo>9"
11:48:25 Schrompf: wenn du zufällig die karo10 wählen *würdest*, dann wäre die gruppe der "kleiner als fiktive karte karo>9" halt 0 karten breit
11:49:08 Schrompf: dann ist der zweig tot. aber das juckt nicht, weil du trotzdem da reiniterieren kannst und einen zahlenbereich hast, in dem sich der wert befinden muss, und dieser range ist der einzig relevante für die anzahl outcomes "gewonnen" oder wasweißich
11:49:18 IceMichael: aber sagen wir Karo Ass oder Karo König als 3. Karte (oder welche Stufe das jetzt ist), macht eben nen Unterschied. Auf dieser Baumstufe hier unterscheiden wir dazwischen nicht, ist beides >karo 9
11:49:32 Schrompf: richtig
11:49:37 IceMichael: dann müssen wir, um die Unterscheidung zu sehen, ja eine Stufe darunter diese Unterscheidung treffen
11:49:45 IceMichael: oder wann auch immer
11:50:07 Schrompf: ja, irgendwann schon. aber in der vierten stufe kannst du erstmal einfach abstrakt weiterrechnen
11:50:12 IceMichael: so und das war meine Aussage eben:
11:50:21 Schrompf: "ich bin jetzt im Zweig Karo9, Rot4, Karo>9"
11:50:28 IceMichael: durch so was wie >karo 9, müssen wir für EINE Karte (unsere karo Dame z.B.) auf mehreren Stufen drauf rumhampeln
11:50:47 Schrompf: warte mal
11:50:48 IceMichael: es wird erst durch >karo 9 abgedeckt und später noch durch == karo Dame
11:50:58 Schrompf: "ich bin jetzt im Zweig Karo9, Rot4, Karo>9"
11:51:17 Schrompf: "es gibt jetzt die farboptionen Karo, Rot, WasNeues"
11:51:47 Schrompf: "es gibt jetzt die Wert-Optionen <4, 4, 5..8, 9, >9..UnserWert, UnserWert, >UnserWert"
11:51:59 Schrompf: du hast einfach nur eine werte-unterteilung mehr
11:52:18 Schrompf: und kannst abstrakt damit weiterrechnen, und es ist dir wurscht, welcher konkrete wert rausgekommen ist
11:52:54 IceMichael: ja, an der Stelle schon, aber später muss ich den konkreten Wert evtl. prüfen
11:53:32 Schrompf: ja, später schon, aber hier nicht. wenn sich dann herausstellt, dass die erste karte des flops ne karo10 war, dann weißt du, dass dein zweig >9..UnserWert halt keine karte enthalten kann, weil >9 aber <10 nicht existiert
11:53:44 Schrompf: aber es hält dich nicht davon ab, einfach die zweige weiter runterzutingeln
11:53:53 IceMichael: ok, aber ich versteh noch nicht, was ein Aggregatzweig wie ">karo 9" bringt, glaub ich
11:54:07 Schrompf: weniger optionen beim zweigaufbau bringt das
11:54:50 IceMichael: ich muss die Fallunterscheidungen doch später eh auf der nächsten Stufe einführen, anfangs muss ich doch alles covern
11:55:33 Schrompf: ja, später auf jeden fall. irgendwo da wird's auch einfach einfacher zu coden, wenn du bruteforce alle möglichkeiten durchgehst
11:56:01 Schrompf: aber das kannst du mit ein bissl geschicktem gebastel wirklich bis in die letzten zwei teilstufen schieben, die du eh nicht mehr behälst
11:56:09 IceMichael: ja und wenn ich es eh muss, seh ich keinen Sinn in dem ">karo 9", ich habe weiter oben weniger Zweige, aber die kommen ja unten dafür wieder dazu
11:56:18 IceMichael: ich erhöhe also erstmal nur die Zahl der Knoten
11:56:29 Schrompf: ja, ein paar kommen dazu, die du mit konkreten werten evtl. als "null breit" ausschließen könntest
11:56:39 Schrompf: kannst du für die randfälle "ass" und "zwei" auch so
11:56:45 Schrompf: ansonsten aber nicht
11:56:56 Schrompf: aber ich *glaube*, dass ich dadurch keine große verschlimmerung ergibt
11:57:10 IceMichael: ja, kann sein, aber ich seh den Vorteil nach wie vor leider nicht...
11:57:13 Schrompf: du bist ja trotzdem in der ersten stufe mindestens von 50 auf 13 optionen runter
11:57:21 Schrompf: allein in der ersten stufe
11:57:24 IceMichael: hm ich muss doch eh alle durchgehen?
11:57:29 Schrompf: nein, nicht einzeln
11:57:43 Schrompf: sondern als paket für alle "karo9, rot4, karo>9"
11:57:44 IceMichael: ok, aber was da gut ist und was nicht, weiß man vorher ja eh nicht
11:57:54 IceMichael: das ist ja jetzt willkürlich da so hingesetzt?
11:58:05 Schrompf: was?
11:58:08 Schrompf: die karo>9
11:58:10 IceMichael: ja
11:58:12 Schrompf: die ist eine variable
11:58:15 Schrompf: ein platzhalter
11:58:30 Schrompf: eine karte, deren konkreten wert du nicht kennst, aber deren wertebereich
11:58:35 IceMichael: was davon? karo>9 ist doch ne Regel und keine Variable
11:58:46 Schrompf: du kannst das gerne nennen, wie du willst
11:59:00 IceMichael: ich würd in die Tabelle schreiben: karo9, karo10, karoJ
11:59:08 Schrompf: es ist ein wertebereich, eine eingrenzung der möglichkeiten aller 50 karten,d ie an der stelle sonst kommen könnten
11:59:12 IceMichael: und ob jetzt >karo9 stattdessen als ein Zweig ggü. 5 (wie viele auch immer) besser ist, weiß man doch nicht
11:59:22 IceMichael: ist auch nicht schlimm, lösen die Folgezweige ja
11:59:33 IceMichael: aber ich seh gerade keinen Anlass dazu >karo9 dafür hinzuschreiben
11:59:36 Schrompf: doch, es sind 1 anstatt fünf zweige, und alles, was du darunter ausrechnest, gilt für all diese fünf werte gleich
11:59:48 xq: https://stackoverflow.com/a/8790495
12:00:19 IceMichael: aber ich hab darunter doch andre Teilbäume
12:00:20 Schrompf: xq: mein beileid
12:00:30 Schrompf: ja, aber für all diese teilbäume gilt das selbe setup
12:00:35 xq: Ctrl+D ist ein verfluchtes "Auto-Fuckup"
12:00:51 IceMichael: na ja, ich hab >karo 9 und darunter dann eben =karo9, =karo10
12:01:03 IceMichael: äh =karo10, karoBube etc. (karo9 obv nicht)
12:01:28 IceMichael: da kann ich doch karo10, karoBube direkt hochziehen. Sonst lauf ich mit z.B. karo Dame in den Zweig rein und prüf genau dasselbe auf der nächsten Ebene wie sonst eins weiter oben
12:02:02 Schrompf: es kann halt Karo10 bis KaroAss sein
12:02:16 IceMichael: ja, schon klar
12:02:21 Schrompf: und entweder du zieht einen zweig für Karo10, KaroBube, KaroDame, KaroKönig hoch
12:02:32 Schrompf: oder du ziehst einen zweig für alle zusammen hoch
12:02:48 IceMichael: ja und wenn ich für alle zusammen hochziehe, hab ich die 5 Einzelteile wieder nen Zweig darunter oder zwei Zweige darunter
12:02:51 Schrompf: weil du doch im folgezweig dann eh wieder nur < == > unterscheidest
12:03:36 IceMichael: sorry, ich seh irgendwie echt keinen Gewinn
12:03:46 IceMichael: ich steh wieder irgendwo auf dem Schlauch, glaub ich
12:03:53 IceMichael: ich sehe, man kann beides so aufbauen, klar, beides geht, gleiches Ergebnis
12:03:55 Schrompf: richtig, du schiebst die weiter rein. du reduzierst die anzahl optionen, und zwar vor allem da, wo's weh tut: am anfang der kombinatorischen explosion
12:04:07 IceMichael: aber ich kann da doch eh NIE stoppen
12:04:23 IceMichael: also spar ich doch nichts
12:04:25 Schrompf: doch
12:04:31 IceMichael: ich muss doch da immer weiter absteigen
12:04:51 Schrompf: du ersparst dir die unterteilungen der stufe vier bis sieben für 4 der fünf möglichen karo>9-karten
12:05:05 IceMichael: na und?
12:05:07 Schrompf: du würdest an der stelle doch in karo10 absteigen und dort *alle* optionen durchgehen
12:05:21 Schrompf: und dann in karoBube absteigen und *alle* optionen nochmal durchgehen
12:05:26 Schrompf: und so weiter
12:05:57 IceMichael: hm wieso, ohne so waas wie ">karo 9" würde ich pro neue Karte exakt eine Stufe haben
12:05:59 Schrompf: so steigst du einmal in den subzweig "abstrakt karo>9" hinter, rechnest *einmal* alle optionen durch
12:06:01 IceMichael: und auch nur diese neue Stufe prüfen
12:06:27 Schrompf: nein, du musst ja alle möglichen karten prüfen
12:06:55 IceMichael: aber doch nicht die, die ich vorher schon geprüft hab?
12:07:16 IceMichael: 3. Karte kommt: ich hab eine Stufe mit einem Zweig pro Karte. Also prüf ich 3. Karte EINMAL gegen alle Zweige und geh in den jeweiligen Zweig. Karte 3 ist fertig
12:07:33 IceMichael: und ab jetzt geht es um Karte 4
12:07:37 Schrompf: nein
12:07:39 IceMichael: wieso nicht?
12:08:08 Schrompf: weil einmal die 3. karte wählst und dann dafür die karte 4 durchprobierst
12:08:24 Schrompf: und dann wählst du eine andere 3. karte und durchprobierst alle 4. karten
12:08:31 Schrompf: du baust du kombis auf
12:09:55 IceMichael: ja und mit dem "karo 9" mach ich dasselbe, nur dass sich 3.Karte auswerten auf zwei Stufen verteilt
12:10:24 IceMichael: da sind 5 Optionen, ich prüfe 5 und sehe "ah >9 ist erfüllt". 1 Vergleich. Im nächsten Zweig prüf ich 10,bube,dame,könig,ass. 5 Vergleiche
12:10:40 IceMichael: wenn ich alles hochziehe, prüfe ich direkt 10,bube,dame,könig,ass. ALso nur 5 statt 6 Vergleiche
12:10:53 IceMichael: und für Karte 4 ist es völlig egal
12:10:59 IceMichael: die prüf ich danach ja so oder so
12:11:10 Schrompf: das ist ne rekursion IceMichael
12:11:26 Schrompf: du prüfst nicht alle 3. karten und danach separat alle 4. karten
12:11:34 IceMichael: ist doch wurscht
12:11:38 IceMichael: ich muss erst alle 3. Karten prüfen und dafür alle 4.
12:11:38 Schrompf: nein, das ist der kern
12:11:51 IceMichael: sagen wir, es sind 40 4.Karten
12:12:10 IceMichael: ob ich jetzt eben die 5 vergleiche vom ersten Teil hab oder die 6 vom in meinen Augen schlechteren Szenario mit >karo9
12:12:23 IceMichael: diese 40 prüf ich doch in beiden Fällen für jede der 3. Karten
12:12:44 IceMichael: ich muss erstmal genau wissen, was die 3. Karte ist, bevor ich alle 4. abklappere
12:15:32 IceMichael: also ich könnte auch erst "3. Karte >karo 9" schauen, dann dafür alle 4. Karten abklappern und DANACH genau schauen, was die 3. Karte ist
12:15:38 IceMichael: aber genau schauen, was die 3. Karte ist, muss ich irgendwann
12:15:48 Schrompf: richtig. aber erst weiter drin
12:15:55 IceMichael: ja und, was nützt das? ich MUSS durch
12:16:01 Schrompf: du sparst dir halt vier von fünf kompletten teilbäumen
12:16:29 Schrompf: und jeder dieser teilbäume ist immer noch millionen möglichkeiten dick
12:16:49 IceMichael: aber wenn ich mit karo Dame hier reinlaufe, dann geh ich doch nur in exakt einen Teilbaum, wieso sind die vier anderen wichtig?
12:17:17 IceMichael: hm, ich muss mal mittag machen, sorry...
12:17:32 IceMichael: also ich glaube, einen Baum aufzuspannen, dann zu schauen, was man aggregieren kann und dadurch zu optimieren, kapier ich
12:17:38 IceMichael: das ist schon mal supernützlich, daher danke :)
12:17:46 IceMichael: das mit >karo 9... komm ich wohl nicht hinter
12:17:57 Schrompf: ok
12:18:02 IceMichael: bin ich einfach zu doof für
12:41:00 IceMichael: verdammt, ich will das verstehen :D
12:41:14 IceMichael: vll mal ich auch mal was
12:41:54 IceMichael: oder besser pseudo-code
12:52:30 IceMichael: ok, also hier ist, wie ich die zwei unterschiedlichen Bäume verstehe und wieso ich nicht kapiere, wo der Vorteil sein soll:
12:52:32 IceMichael: https://ideone.com/jNnN99
12:52:55 IceMichael: wir gehen im Endeffekt immer alle Endzustände durch (beim Aufbau des Baums ohne dass wir bereits Zeug zusammengefasst haben)
12:53:59 IceMichael: ergo: mir fehlt irgendeine Info, die für dich vermutlich zu trivial ist, um sie für mich zu erwähnen, für die ich aber zu doof bin, sie zu sehen :D
13:12:26 Schrompf: sorry, das hat heute schon zuviel zeit gefressen
13:12:39 Schrompf: und ich hab ein arbeitsmeeting so verkackt, dass es sichtbar wurde.
13:23:44 IceMichael: klingt gar nicht gut
13:24:00 IceMichael: ja, kein Thema, lassen wir das. Danke trotzdem!
13:24:24 IceMichael: Hilft wsl nicht, aber bei meiner Firma verkack ich gerade auch eher hart seit ner Weile
19:01:03 Schrompf joined the channel
19:54:53 Ompf joined the channel
22:27:41 Magister joined the channel