06:12:20 Schrompf joined the channel
06:30:12 Hannes joined the channel
06:30:56 Hannes: Guten Morgen
06:37:05 Schrompf: < > Morgen
06:39:26 Hannes: Wunderhübschen Morgen?
06:40:34 Schrompf: müdepipikalt
06:40:44 Schrompf: off to bed auf arbeitgeberkosten
07:13:45 IceMichael: Guten Morgen
07:15:29 Schrompf: hi
07:19:52 Hannes: Guten Morgen IceMichael
07:20:40 IceMichael: na, wie läuft's bei euch?
07:22:46 Schrompf:
08:05:59 xq: moin moin
08:07:02 Hannes: Guten Morgen xq
08:13:05 xq: https://github.com/ziglang/zig/pull/8266#issuecomment-804533619
08:13:22 xq: Schrompf: der performance-boost von Data-Oriented Design :O
08:15:04 Schrompf: hm
08:15:58 xq: fast 160% schneller
08:16:12 xq: bbzw. 60% schneller, 160% orginalgeschwindigkeit
08:49:13 Schrompf: was ist soviel schneller?
08:49:34 xq: der compiler
08:49:47 xq: in dem fall: 1 mio lines of "hello world!" printing compilieren
09:09:36 Hannes: klingt nach nem spannenden textadventure ;-)
09:10:08 Schrompf: ah, nice
10:03:39 IceMichael: xq, was genau wurd da jetzt umdesigned? Ich kenn data-oriented von so was wie vector von x,y,z statt vector
10:09:47 xq: genau das
10:09:52 xq: also, zum einen
10:09:59 xq: zum anderen sehr viel speicheroptimierter
10:11:19 IceMichael: ok nice :)
10:11:46 IceMichael: und x,y,z vs struct
10:14:49 xq: naja, was du machst ist, die optimierst deinen code auf zugriffspatterns
10:16:23 xq: also du legst die daten in strukturen an, die halt besser optimiert sind
10:16:43 xq: jetzt []vec3 auf []x, []y, []z aufzusplitten macht wenig sinn
10:16:54 IceMichael: ja, die Idee von DOD ist mir an sich klar, hätte mich jetzt nur interessiert, ob es da konkrete Beispiele im Compiler gibt, die man ohne viel background nachvollziehen kann
10:17:09 xq: beispiel wäre: AST-Nodes kleiner machen
10:17:26 IceMichael: ja, verstehe
10:17:41 xq: und halt dinge nicht "speichern", die nicht gespeichert werden müssen
10:20:06 xq: also im fall vom tokenizer: "nicht die location für jeden token speichern"
10:20:14 xq: sondern zum beispiel "diese deklaration fängt an X an"
10:20:41 xq: aber dann für alle bestandteile der AST-Node nicht speichern
10:20:43 xq: du kannst ja retokenizen
10:22:04 IceMichael: ok, klingt nach viel Benchmarking, um rauszufinden, wo das sinnvoll ist und wo nicht
10:22:14 IceMichael: oder viel "im Code drin sein" einfach
10:22:56 xq: eher "nachdenken" :D
10:23:05 xq: die primäridee ist ja: "weniger speicher => schneller"
10:23:31 IceMichael: ja, ist halt immer ein Tradeoff
10:23:53 xq: naja, "codingzeit" vs. "executiontime"
10:24:38 IceMichael: ich mein eher, dass manchmal mehr Speicher in redundanten Strukturen oder einfach durch Caches (ja auch oft mehr Speicher) wiederum Speed bringen können
10:25:11 IceMichael: wenn wenig Speicher immer am besten wär, könnt ich ja immer alles live neu berechnen, das wär offensichtlich ungeil
10:25:18 IceMichael: na ja, aber das ist eh klar
10:25:59 xq: caches sind übrigens auch ne speicherreduktion :D
10:26:08 xq: also, wenn sie gut gemacht sind
10:26:20 xq: weil du auf immer den gleichen speicher zugreiffst, statt zu suchen
10:26:56 IceMichael: ja logisch. Aber nicht immer reduziert ein Cache ja den Speicher an anderer Stelle
10:27:01 IceMichael: man kann z.B. Rechenergebnisse cachen
10:27:21 xq: jo, das lohnt aber nur, wenn die rechenergebnisse sehr aufwändig sind
10:27:29 xq: schönes beispiel:
10:27:34 IceMichael: jap
10:28:23 IceMichael: bei meinem Pokerkram hab ich ja sehr aufwändige Rechnungen. Am besten wär, ich könnte alles cachen/lookupen. Ist aber zu viel, daher muss ich ja so einen komplexen Regelbaum aufstellen. Kostet schon trotzdem viel Speicher, aber alles live zu berechnen ist halt viel zu langsam
10:28:30 xq: L3-Cache-Miss sind halt irgendwas zwischen 250 und 750 cycles
10:31:30 xq: was sind bei deinen pokeralgos denn der input?
10:32:38 IceMichael: Karten von Spieler1, Karten von Spieler2 und das "Board" (Karten in der Mitte, die können beide Spieler benutzen, ohne sie aufzunehmen)
10:32:57 xq: okay, also nichts relevant großes
10:33:09 xq: sowas wie 16 byte oder so :D
10:33:21 IceMichael: ein lookup hätte 52*51/2*50*49/2 / 2 * 48*47*46*/3/2 Möglichkeiten
10:33:38 IceMichael: also 14 Mrd.
10:34:06 xq: ja, dein problem ist halt, dass dein problem exponentielles wachstum hat
10:34:11 xq: und dein suchbaum scheiße groß ist
10:34:22 xq: da kommste auch nur mit big-o-optimierung wirklich weiter
10:34:38 IceMichael: ja, ich suche auch schon seit ner Weile nach Regeln zur Eingrenzung
10:35:08 IceMichael: wenn es richtig generalisierbar sein soll, gibt es wenig. Ich schaue mir gerade gewisse Subsets von Problemen an und baue Regeln auf, schaue, wie die sich generalisieren, verfeinere sie
10:35:23 IceMichael: manchmal kann ich dann 192 Möglichkeiten auf eine reduzieren, manchmal 256 auf 10
10:35:35 IceMichael: aber ist noch viel Arbeit vor mir :/
10:36:28 IceMichael: Das Gemeine ist, dass der Raum von möglichen Regeln auch zu groß ist, um das zu automatisieren
10:36:44 xq: ja, das klingt aber relativ gut zum optimieren
10:36:48 xq: faktor 256 schneller ist nice
10:37:39 IceMichael: na ja, es ist nicht ganz schneller. Der Regelbaum führt dazu, dass ich z.B. einen von 256 Fällen berechnen muss, und 180 per lookup kriege. Aber vor dem möglichen lookup muss ich natürlich die Hand/Hand/Board-Kombination erstmal durch den Regelbaum prüfen
10:37:49 IceMichael: das ist natürlich viel schneller als es durchzurechnen, aber nicht komplett vernachlässigbar
10:38:07 Schrompf: deswegen kam ja mein vorschlag mit den abstrakten karten, wodurch du halt 5:1 reduktion kriegst, aber *in jeder baumstufe erneut*
10:38:36 IceMichael: ja, das Problem ist, dass sich leider nie Karten zusammenfassen lassen
10:38:40 IceMichael: oder sehr, sehr selten
10:39:00 Schrompf: ne, das hatten wir ja durchdiskutiert. in meiner welt ging das immer
10:39:00 IceMichael: was passiert ist eher, dass es sehr viele Regeln gibt, unter denen man die Farben untereinander austauschen kann (bei gleich bleibenden Werten)
10:39:29 Schrompf: aber die stoßrichtung ist klar: du musst deinen baum kleiner kriegen
10:39:58 IceMichael: genau, aber ich kann nicht auf jede Baumstufe einfach Karten setzen und hoffen, dass ich dadurch was eingrenze
10:40:02 Schrompf: das Data-Oriented Design, von dem xq sprach, ist ne Mikrooptimierung - der algorithmus ist gleich
10:40:18 Schrompf: das bringt in deinem ganz konkreten beispiel nix
10:40:21 IceMichael: denn bei der Struktur lauf ich doch immer nur in jeden Zweig rein und kann nichts aggregieren
10:40:25 IceMichael: jap, ich weiß
10:40:28 xq: vorallem weil IceMichael nicht data-bound ist
10:40:36 xq: das wäre was, wo Schrompfs voxel schneller werden
10:40:37 Schrompf: doch, doch, das war der punkt, wo wir letzens auseinander gegangen sind
10:40:40 xq: weären die nicht schon hart optimiert
10:41:17 IceMichael: also ich hab das ja probiert, was du gemeint hast, Schrompf. Ich hab mir einfach mal ein fixes Board genommen, ne fixe Hand von Spieler1 und dann die Spieler2-Hände als Input (also in zwei Baumstufen)
10:41:29 IceMichael: Resultat war, dass in den Zweigen immer unterschiedliche Werte standen -> nix zu aggregieren
10:41:39 IceMichael: ich hatte nur den Overhead, dass ich erstmal durch den Baum stiefeln musste, um das rauszufinden :D
10:41:50 Schrompf: you're doing it wrong :-)
10:42:21 Schrompf: ist aber egal, mach halt. ich wollte eigentlich nur darauf hinaus, dass xq's bericht hier ne andere sportart ist als deine lösungsansätze
10:42:29 Schrompf: du musst die komplexität runterkriegen
10:42:30 IceMichael: ja, das ist mir eh klar
10:42:35 Schrompf: gutgut
10:42:38 IceMichael: hast du nen Artikel oder so zu deiner Idee?
10:43:01 IceMichael: ich hab dein Bild noch paar anderen Leuten gezeigt (aber ohne deine Erklärung), da wussten die auch entweder nicht, was gemeint ist, oder stimmten mir zu, dass das bei Poker gar nix bringt
10:43:04 Schrompf: nein, die hab ich live entwickelt. keine ahnung, ob's sowas schon gibt und unter welchem begriff das laufen könnte
10:43:04 xq: du bist hier der mit der domain knowledge
10:43:04 xq: :D
10:43:14 Schrompf: genau
10:43:20 IceMichael: ja und nach meinem Domain knowledge bringt der Baum nichts
10:43:26 IceMichael: nicht so, wie ihn Schrompf gebastelt hat
10:43:36 Schrompf: ich bin der, der da rein mathematisch rangeht. es gibt diese elemente der menge, und deine fallunterscheidungen teilen diese menge in gruppen auf
10:43:38 xq: haben die farben in poker werte?
10:44:01 IceMichael: prinzipiell nicht, also pik ist nie höher als kreuz oder so
10:44:26 Schrompf: was wäre denn, wenn einer ein paar rot9/karo9 hat und der andere ein kreuz9/piek9?
10:44:31 Schrompf: split?
10:44:45 IceMichael: bei twopair entscheidet die 5. Karte
10:44:49 Schrompf: ah
10:44:55 IceMichael: das hat mit der Farbe nichts zu tun. Wenn die aber gleich hoch ist bei beiden, dann split
10:45:14 Schrompf: also nichtmal in grenzfällen ne farbunterscheidung
10:45:21 IceMichael: genau
10:45:35 IceMichael: daher ja überhaupt das Potential
10:46:14 IceMichael: moment, ich hab ein Beispiel aus meinem Code. Die vier Farben sind ja UTF-8 Symbole und Farbe geht im Terminal, daher geb ich mir gerade alles schön aus :D
10:46:59 IceMichael: die hier sind z.B. gleich: https://ibb.co/NFCQ6Kz
10:47:07 xq: bist du auf linux oder hast eines zur hand?
10:47:15 IceMichael: nur terminalmäßig
10:47:20 xq: reicht
10:47:20 IceMichael: aber kein starkes, nur so schwache Pis
10:47:25 xq: ah, poop
10:47:36 xq: weil sonst würde ich sagen, wirf mal "perf stat" auf dein problem
10:47:43 xq: isolier deinen algorithmus, lass ihn ein paar mal rennen
10:47:47 xq: und schau, was das ausspuckt
10:48:15 IceMichael: also in dem Beispiel ist es jetzt z.B. supereasy, weil von rechts nach links gelesen eigentlich ne Gruppe entsteht
10:48:26 IceMichael: aber es fasst vier zusammen, das ist erstmal wenig
10:49:03 IceMichael: aber oft hat man Gleichheiten, wenn sich die Hand von Spieler1 in "derselben Weise" farblich ändert wie die von Spieler2
10:49:20 IceMichael: und da bringt mir der Baum leider nichts, falls ich ihn so aufbaue, dass von links nach rechts Karten der Spieler abgetragen werden
10:50:10 IceMichael: mein Baum ist gerade eher so: Stufe 1) Board rainbow (drei verschiedene Farben)? 2) Hand 1 in einer Farbe? 3) Falls ja, könnte die mit zwei weiteren Karten nen Flush machen? 4) Falls ja, hat Spieler2 in einer Karte ne Farbe des möglichen Flushs? 5) Falls ja, wie hoch ist die... etc.
10:50:38 IceMichael: ich hab erst die einfachsten Regeln probiert und taste mich langsam weiter runter. Ich kann später noch ein bisschen hin- und herhampeln, aber das ist dann im Prinzip die einfachste Eingrenzung, die möglich ist
10:51:24 IceMichael: denn ich sehe für jede Gruppe in meinem Output ja die Zahl der Kombinationen und wenn zwei gleich sind, fass ich sie zusammen (oder auch nicht, weil es oft sinnvoller ist mehr Fälle zu covern als weniger Gruppen zu haben)
10:52:24 IceMichael: Problem: das kann man nicht automatisieren oder es wäre langsam, weil man bei dem Powerset an Regeln ebenfalls schnell explodiert
10:52:52 IceMichael: oder ich brauch einen sauschlauen Regelfinde-Algorithmus, aber da müsst ich halt erst wochenlang Theorie pauken
10:53:19 xq: ich denk ohne schlaue regelfindung wirst du aber nicht besser
10:53:43 IceMichael: wie man's nimmt, ich erschlage für Rainbow-Boards ja schon sehr, sehr viele Fälle
10:54:14 IceMichael: es bleiben halt Ausnahmen, denen ich mich mit viel Liebe noch widmen muss
10:54:31 IceMichael: ist halt so oder so Scheißarbeit :/
10:55:53 IceMichael: ich hab auch überlegt, automatisiert alle möglichen Regeln aufzustellen, ist aber einfach zu viel, das muss man nachher halt kombinieren
10:58:41 Schrompf: da die reihenfolge ja egal ist, kannst du ja ne sortierung einziehen
10:59:10 Schrompf: die farbe hast du ja schon neutral gerechnet und rechnest nur "eine der vorherigen farben nochmal" oder "neue farbe"
10:59:11 IceMichael: du meinst, Reihenfolge der Karten? Ja, das ist eh schon alles drin
10:59:31 Schrompf: und wenn du jetzt noch beim aufbau des baumes den wert sortierst
10:59:57 IceMichael: ja, reicht leider trotzdem nicht..
11:00:08 Schrompf: also "wenn ich als erste karte ne 10 habe, dann muss ich als zweite karte nur noch 10 anderer farbe oder <10 durchgehen"
11:00:20 Schrompf: weil >10 wäre ein anderer startzweig
11:00:27 Schrompf: verstehst du, was ich meine?
11:00:42 Schrompf: bringt dir nur ein amortisiertes /2, aber immerhin
11:00:56 IceMichael: die Unterscheidung ist leider nicht sinnvoll
11:01:00 IceMichael: hatten wir ja schon
11:01:05 Schrompf: du schon wieder. doch, die funktioniert.
11:01:08 IceMichael: nein
11:01:15 Schrompf: machen wir mal ein beispiel
11:01:21 IceMichael: also im Poker-Domänenwissen macht es keinen Sinn
11:01:41 IceMichael: im rein algorithmischen ist es erstmal nur ne Aufteilung
11:02:08 Schrompf: och weißt du. es geht. es funktioniert. aber ich habe nicht mehr den nerv, das nochmal aufzudröseln. dann mach halt.
11:02:35 IceMichael: es hängt halt davon ab, ob du jetzt mit Poker argumentierst oder algorithmisch, das sind zwei paar Schuhe
11:02:58 IceMichael: algorithmithisch kann es sauschlau sein, ich versteh nur evtl. die Idee nicht
11:03:20 IceMichael: im Pokerwissen: nein, einfach nein. Du wusstest ja vorhin nicht mal, wie die Splitregel bei Twopair ist, da müsstest du einfach estmal das Wissen aufholen
11:04:21 IceMichael: und so einen Baum aufzustellen, bringt ja nur dann was, wenn ich irgendwo irgendwann mal was aggregieren kann
11:04:54 IceMichael: wenn nicht, nehme ich einfach alle 12 Mrd. Fälle und stecke sie in 12 Mrd. Zweige von einem Riesenbaum
11:05:41 Schrompf: ja, das geht auch. aber es geht auch besser
11:06:51 Schrompf: vor allem massiv besser, fällt mir gerade auf
11:06:53 Schrompf: hossa
11:07:32 Schrompf: wir wollen ja von nem set karten die summierten erfolgschancen haben: wieviele aller möglichen kartenkombis gewinnen, wieviele verlieren, usw
11:08:46 Schrompf: wenn wir also davon ausgehen, dass wir die zu betrachtende spielsituation eh immer a) nach farbe und b) nach kartenwert sortieren
11:09:59 Schrompf: dann können wir mit nem vollständigen start-satz (13 karten einer beliebigen farbe, die absofort F1 heißt)) alle möglichkeiten aufbauen
11:11:00 Schrompf: wir können im zweig DameF1 ja alle Optionen >DameF2 und alle Optionen >BubeF1 ausschließen
11:11:21 Schrompf: denn die wären ja durch die Sortierung der Spielsituation in nem anderen Startzweig behandelt. die können wir in diesem Teilbaum komplett weglassen
11:15:50 Schrompf: wenn man das weiter denkt, kann man sehen, dass in jeder stufe des baumes die werte recht beschränkt sind. es kann immer nur eine karte mit wert <= bisheriges minimum dazukommen
11:16:18 Schrompf: denn eine karte mit wert >= bisherige kleinste karte wäre weiter draußen in einen anderen zweig abgestiegen
11:17:52 Schrompf: das bedeutet, dass Du mit dem Einstieg AssF1 die meisten Teilzweige hast, nämlich "KönigF1 und weniger" oder "AssF2 und weniger". 25 karten. doof, aber immerhin schon die hälfte
11:18:25 Schrompf: bei ner NeunF1 bist Du schon nur noch bei 15 teilzweigen.
11:21:34 Schrompf: wenn du jetzt bei der NeunF1 als nächsten Subzweig ne SechsF2 betrachtest, würden sich für die nächste Stufe nur noch SechsF3et.al. anbieten.
11:22:57 Schrompf: ne moment. es gibt keine totale ordnung.
11:23:19 Schrompf: na doch, gibt's
11:26:41 Schrompf: wenn man sortiert nach "Farbe nach Anzahl Karten" und dann als Unterkriterium nach Wert, dann ergeben sich überschaubare regeln
11:26:53 Schrompf: für jeden WertF1:
11:27:18 Schrompf: - zweite Stufe des Baumes kann maximal
11:27:40 Schrompf: Denn >WertF1 wäre ein anderer Startpunkt
11:28:10 Schrompf: Und >WertF2 würde F2 zur neuen F1 machen und beim Startpunkt DieserWertF1 mit dem Baum-Abstieg beginnen
11:29:10 Schrompf: jetzt die zweite Stufe der Aufteilung. Wir sind entweder in der allgemeinen Situation W1F1, W2F2
11:30:14 Schrompf: dann gibt's nur
11:30:43 Schrompf: und WxF2 würde F2 zur zahlenmäßigen Führungsfarbe und damit zu F1 machen, und die Optionen haben wir ja schon in anderen Startknoten behandelt
11:32:20 IceMichael: so sorry, ich les gleich
11:32:36 IceMichael: Schwiegermutter wurde vom Microsoft-Mitarbeiter angerufen :(
11:32:45 Schrompf: orneee
11:34:10 IceMichael: jap, ihr Sohn geht später mit Linuxstick drauf und rettet Daten. Ich hoffe, er hat die HDD nicht verschlüsselt oder zu viel gelöscht
11:35:47 IceMichael: ich geb mal Zwischenkommentare chronologisch: also genau, durch Sortierung geht so was wie Dame-König nicht, weil es immer König-Dame wäre. Selbiges für die Farben. Daher hab ich ja schon gesagt, es sind 48*47*46 / 3 / 2 Boards, alles schon drin :)
11:36:34 IceMichael: bzw. Sorry, das sind nur Permutationen, ja, nochmal /2
11:38:05 IceMichael: ich glaub, hier hakt's leider etwas " wenn man sortiert nach "Farbe nach Anzahl Karten" und dann als Unterkriterium nach Wert, dann ergeben sich überschaubare regeln", vll aber auch mein Verständnis
11:38:15 IceMichael: denn welche Farbe zu welchem Wert gemappt ist, ist schon wichtig
11:39:12 IceMichael: also klar, nicht in jedem Fall. Wenn ich Situationen schaffe, in denen ich wirklich nur Farben ausgetauscht hab, dann hab ich da natürlich die gleiche Situation
11:40:01 IceMichael: aber: wenn in der Mitte die drei Karten drei unterschiedliche Farben haben (rainbow), dann bringt die "sortiere Hände nach Farben"-Regel leider nichts
11:40:42 IceMichael: sorry, meintest du mit <10 und >10 einfach das, dass ich die Karten vorher sortiere und daher einfach die Duplikate rauswerfe?
11:41:04 IceMichael: weil falls ja... ja gut, natürlich geht das, das ist ja trivial
11:42:36 IceMichael: Problem ist halt: das reicht alles noch nicht aus :/ es reduziert stark, ja, aber ich brauch mehr und da kommen eben komplexere Regeln ins Spiel
11:47:45 IceMichael: also diese Sortierung rechnet im Prinzip immer Permutationen raus. Drei Karten in der Mitte sortiert (weil Reihenfolge egal, aber Farbe nicht) führen zu 22100 (52*51*50/3/2) Situationen. Das multipliziert man halt eben mit 49*48/2 (beiden Karten Spieler1, Farbe noch drin) * 47*46/2 (beide Karten Spieler2, Farbe auch noch drin) / 2 (wir brauchen nicht Hand1 vs Hand2 doppelt anschauen, es ist ja egal, wer was hat) = 583740. Mit
11:47:45 IceMichael: 22100 multipliziert halt noch 13 Mrd. (gut, das hab ich vorhin falsch berechnet, hab wohl ne /2 vergessen)
11:49:02 IceMichael: ob man ne Farbe durch ne andere austauschen kann, liegt leider auch daran, ob ein Spieler z.B. ein Pärchen hat (inkl. der Karten in der Mitte eben). Denn dann ist nicht jede Farbe austauschbar, weil der Spieler mit dem Pärchen durch das, was dem anderen nen Flush bringt, evtl ein Full House machen kann und den Flush schlägt. In anderen Farben nicht
11:50:13 IceMichael: wenn beide auf denselben Flush zielen, kann die Farbe wichtig sein, weil ein Spieler in ner anderen Farbe vielleicht Flush+Straße auf einmal kriegen kann (Str8flush), was den anderen Spieler schlägt, der aber in anderen Farben immer den besseren Flush hat
11:50:40 IceMichael: (Flush: 5 Karten in einer Farbe, oft stark, manchmal nicht)
11:54:52 IceMichael: na ja und so gibt's halt noch zig Extraregeln...
12:03:28 Schrompf: Die Pokerregeln sind da schnuppe, das sind nur bewertungen der einzelnen spielsituationen, und wir mappen ja spielsituationen auf bewertungsgleiche spielsituationen
12:03:47 Schrompf: und ich sehe nicht, dass das "nur permutationen rausnehmen" ist, sondern es ist halt deutlich mehr
12:03:57 Schrompf: einfach nur die zwei karten der spielerhand
12:04:05 Schrompf: stumpf gerechnet ist das 52*51/2
12:04:27 Schrompf: mit der farb- und wertsortierung ist es aber noch 13 * 25
12:07:52 Schrompf: (weil 13 Karten "einer Farbe" mal "12 Karten derselben Farbe plus 13 Karten einer anderen Farbe")
12:08:12 Schrompf: aber du hast recht, ich habe nicht bedacht, dass man nur innerhalb der besitzgruppen sortieren darf, nicht beliebig
12:08:30 Schrompf: man darf ja nicht die 9 aus der gegnerhand mit der 9 aus der eigenen hand zu nem paar zusammenlegen
12:08:53 Schrompf: diese teilbaum-optimierungen gehen also nur innerhalb eines satzes karten - eigene hand, flop, gegnerhand
12:09:23 Schrompf: es sind also mehr optionen als ich dachte, aber nach meiner betrachtung immer noch *drastisch* weniger als die reine permutationsberechnung aus der stochastik ergibt
12:09:35 Schrompf: mittag ist da, ich bin erstmal wech
12:10:21 xq: es flutscht wahrlich gut
12:10:43 xq: Steam lädt mit 98MB/s runter
12:10:46 xq: sehr befriedigend
12:13:27 Schrompf: das knallt!
12:13:34 xq: ohja
12:13:40 xq: fühlt sich gut an, mal wirklich speed zu sehen
12:14:34 Schrompf: ich hab gerade meinen alten zweitmonitor an einen alten freund "verschenkt" und dafür ne flasche wein und nen döner bekommen
12:14:50 Schrompf: ich werd ganz sentimental dabei, muss diese pandemie sein, von der alle reden
12:16:09 xq: ich werd demnächst meinen "zweitmonitor" auch bespaßen
12:16:20 xq: das ist ne schöne Schwarz-Grün-Röhre
12:18:31 xq: mal schauen, was man da drauf so darstellen kann
13:10:56 IceMichael: diese Regeln sind halt genau der Grund, weswegen dein Ansatz eben nicht verallgemeinbar ist, aber ich les mal weiter
13:11:03 IceMichael: das sind alles Ausnahmen zur Generalisierbarkeit
13:13:12 IceMichael: (weil 13 Karten "einer Farbe" mal "12 Karten derselben Farbe plus 13 Karten einer anderen Farbe"): Ja, man kann das Pferd natürlich auch so rum aufzäumen. Dann muss ich natürlich bei Spieler2 die erste Karte nur mappen auf "ist genau so wie Karte 1 von Spieler1 oder Karte2 von Spieler1 oder eine neue Farbe" usw.
13:14:22 IceMichael: bzw. bei mir ist es ja andersrum, weil der exakte Flop ein Input ist, also würd ich vermutlich den nach vorne stellen
13:15:44 IceMichael: ok, aber mal so bei dir aufgestellt
13:16:46 IceMichael: dann fällt nicht soo viel weg... 13*25*37*49 und danach geht es ja weiter wie vorher
13:17:19 IceMichael: wär also supergrob 1/4*1/2*3/4 = 10% hmm
13:19:20 Schrompf: 10% aller flop-optionen mal 30% aller eigen-hand-optionen mal 30% aller gegnerhand-optionen. macht das ding sicher nicht echtzeitfähig, aber würde die anzahl optionen auf ~1% der ursprünglichen 24 milliarden reduzieren. damit würde die tabelle in den speicher passen :-)
13:19:39 IceMichael: jaa, moment
13:19:44 IceMichael: ich glaube, das ist 10% für alles
13:19:55 IceMichael: das waren jetzt ja 4 Karten, also Hand Spieler1 und Hand Spieler2
13:20:07 Schrompf: nee, du hast gerade 10% der möglichkeiten des flops (3 karten) ausgerechnet.
13:20:12 IceMichael: aber für den Flop muss man schon alles in Betracht ziehen, weil das Verhältnis zur 1. Karte von Spieler1, zur 2. von Spieler 2. usw. wichtig ist
13:20:26 IceMichael: ich hatte vier Faktoren, das ist kein Flop
13:20:35 Schrompf: stimmt.
13:20:37 IceMichael: aber ich hab's da wieder umgedreht und meinte Spieler1 vs. Spieler2 sorry
13:21:01 Schrompf: ahso, der vierer ist "eigene und gegner-hand"?
13:21:12 IceMichael: also ich meinte 13*25 = Spieler1-Hand
13:21:18 IceMichael: und *37*49 = Spieler2-Hand
13:21:28 IceMichael: moment, das ist irgendwie Blödsinn
13:21:49 IceMichael: ah ne, passt
13:22:01 Schrompf: naja, nich ganz. man kann ja die "gleiche oder andere farbe"-optimierung nicht komplett unabhängig auf die zweite hand anwenden
13:22:06 IceMichael: 37 = Farbe von Spieler1-Karte1 ODER Farbe von Spieler1-Karte2 ODER eine der zwei verbleibenden Farben, da 13 Karten je
13:22:51 IceMichael: so meintest du das, oder?
13:22:54 Schrompf: wenn ich mir die chancenanzeige bei nem pokerspiel richtig vorstelle, brauchst du zuerst das ergebnis für "nur eigene hand bekannt", also zwei karten.
13:22:59 Schrompf: genau
13:23:20 Schrompf: und von "eigene hand" aus musst du dann jeweils ne karte mit einberechnen, sobald sie aufgedeckt wird
13:23:40 Schrompf: die karten der gegnerhand brauchst du nie einzeln, sondern immer nur als summe über alle möglichkeiten
13:23:42 IceMichael: genau, aber der User gibt halt beliebig viele Hände von Spieler2, beliebig viele von Spieler1 und genau einen Flop ein
13:24:03 IceMichael: doch, kann schon sein, dass du den Gegner auf exakt eine Hand setzt. Meistens aber beliebig viele, aber fast nie "zufällig"
13:24:13 Schrompf: hä? du bist nicht die anzeige unten mitte, während ein mensch spielt?
13:24:31 IceMichael: Pokerspieler schätzen ein, was der Gegner haben können basierend auf Skill
13:24:41 IceMichael: ich muss schon für jede mögliche Gegnerhand ein Ergebnis liefern können
13:24:53 IceMichael: selbst wenn es nur ist, um zu gucken "was wäre wenn"
13:25:00 Schrompf: sicher. aber die konkrete gegnerhand ist doch nicht bekannt?
13:25:22 Schrompf: da kann man doch einfach am ende für jede kombo "eigenhand plus flop" alle gegnerhände durchgehen und die summe von outcomes merken
13:25:24 IceMichael: spielt keine Rolle, ich stell manchmal ja auch Tabellen dar, wo ich für jede Hand das Ergebnis ausgebe
13:25:32 Schrompf: dann ist deine tabelle doch nur noch ein paar millionen einträge groß
13:25:56 IceMichael: man kann aber auch einem Spieler mehrere Hände geben
13:26:04 IceMichael: für diverse Graphen usw.
13:26:14 Schrompf: und die nehmen alle gleichzeitig am spiel teil?
13:26:27 IceMichael: nee
13:26:47 IceMichael: aber sie sind mit Gewichtung drin und wir wollen wissen, was die Durchschnittschance ist
13:26:49 Schrompf: dann versteh ich nicht, was der einwand soll. ne andere hand ist ein weiterer lookup, nicht mehr tabellengröße
13:27:01 IceMichael: also relevant ist nur:
13:27:25 IceMichael: ich muss eine Hand Spieler1 vs eine Hand Spieler2 für einen bestimmten Flop ausgeben können. Ob ich jetzt 1000 von diesen Abfragen auf einmal mache, ist wurscht
13:27:50 IceMichael: ich kann Millionen solcher Abfragen pro Sekunde machen, die Abfrage selbst muss ich nur eben brav speichern können
13:28:00 IceMichael: also tut alles nix zur Sache
13:28:06 Schrompf: stimmt
13:28:34 Schrompf: das problem ist dasselbe: du brauchst nen baum bis zur fünften karte und darin dann nur die summen über alle outcomes des baums bis zur siebten stufe
13:29:12 IceMichael: hm, aber wenn Spieler1 eine Hand hat und Spieler2 auch exakt eine Hand, dann hab ich die Info wegen der Summe doch nicht?
13:29:17 Schrompf: die siebte stufe ist ein ganz konkreter satz karten "eigene hand" plus "flop" plus "gegnerhand" und hat enum Outcome { Yeah, Meh, Boo }
13:29:36 IceMichael: ach sorry
13:29:40 IceMichael: ne halt hm
13:29:42 Schrompf: stimmt, dann musst du nur anhand der pokerregeln auswerten, welcher der beiden spieler gewonnen hat
13:29:57 IceMichael: also wer wirklich gewinnt zeigt sich ja, wenn 5 Karten in der Mitte sind
13:30:03 IceMichael: das sind dann insgesamt 9
13:30:15 IceMichael: aber ich bin hier explizit nur auf Flopanalyse, also ja: ich merk mir nur die Summe
13:30:23 Schrompf: 9? warst du nicht die ganze zeit bei "zwei eigene, zwei gegner, drei flop"?
13:30:33 IceMichael: ja, das ist der Ausgangszustand und dafür will ich es mir merken
13:30:37 IceMichael: aber da steht ja noch nicht fest, wer gewinnt
13:30:39 Schrompf: dann sind's aber nur 7
13:30:52 IceMichael: genau. Aber dein enum gilt erst, wenn 5 Karten in der Mitte sind
13:31:09 Schrompf: der enum gilt erst für "zwei eigene, drei flop, zwei ganz konkrete gegner"
13:31:20 IceMichael: zwei Gegner?
13:31:29 Schrompf: zwei karten des gegners
13:31:35 IceMichael: ne, dann gilt es noch nicht leider
13:31:47 IceMichael: ab genau dem Zeitpunkt werden später noch zwei weitere Karten kommen (Turn, River)
13:31:49 Schrompf: also zwei plus drei für die beim spiel sichtbaren karten, plus zwei bis zum ende unsichtbare des gegners
13:32:00 IceMichael: auch die können beide Spieler nutzen
13:32:08 Schrompf: ok, das ist nicht mehr das poker, das ich kenne
13:32:19 IceMichael: das ist das bekannteste Poker: Texas Hold'em
13:32:57 Schrompf: ja, das meine ich, aber da kommen keine fünf flopkarten vor, sondern nur drei
13:33:12 Schrompf: aber nuja, gut zu wissen warum du auf neun karten spielsituation kommst
13:33:30 IceMichael: ja, aber dein enum ist ja "Spieler 1 gewinnt (exakt einmal oder null mal), Spieler2 gewinnt (exakt einmal oder null mal) oder Split"
13:33:36 Schrompf: und dein baum ist dann 7 spielkarten tief, die 8. und 9. stufe brauchst du nur in summe
13:33:40 IceMichael: genau
13:34:14 IceMichael: also es gibt auch nur drei Flopkarten, das ist richtig. Die 4. nennt man Turn, die 5. River (gut zu merken, weil die zwei genau so viele Buchstaben haben wie die Zahl der Karten; klappt für Flop natürlich nicht)
13:34:32 Schrompf: wie die dinger heißen ist der mathematik aber egal
13:34:40 Schrompf: und es hätte uns ne menge diskussionen erspart. i
13:34:45 Schrompf: das ärgert mich gerade ziemlich
13:35:19 IceMichael: hm na ja... die Spielkenntnis muss halt da sein
13:35:33 IceMichael: ich wusste nicht genau, wie viel du von dem Spiel weißt und wie viel nicht
13:35:45 IceMichael: aber wenn es jetzt daran lag, dann ja... dann haben wir wohl deswegen ein wenig aneinander vorbei geredet
13:35:56 IceMichael: also viel trifft ja dennoch zu und da ist viel guter Input dabei, nach wie vor
13:48:39 IceMichael: 13*25 ist übrigens auch schon zu viel. Es sind ja nur 25, falls links ein Ass z.B. ist. Wenn links ne 2 ist, gibt es ja sogar nur eine mögliche Karten, da müssen wir also mit gar nix multiplizieren
14:16:59 Schrompf: korrekt. da fällt amortisiert zweimal die hälfte der möglichkeiten raus
14:17:20 Schrompf: ne, ist multiplikativ. also die hälfte
14:17:44 Schrompf: ein königF1 kann nur königf2-- oder damef1-- sein, also dann noch 23 optionen. usw.
14:17:48 IceMichael: ja, ich frag mich gerade, wie viel das für 4 ist
14:18:07 IceMichael: bin aber zu doof zum rechnen gerade, versuche es zu coden, bin aber vermutlich auch dafür zu doof gerade
14:18:30 Schrompf: ich muss eigentlich zum kind und zum zahnarzt. grmpf
14:18:43 Schrompf: zwei karten haben wir gerade: 13 * (25, 23, 21, 19, ...)
14:18:51 IceMichael: hm, das ist womöglich auch wichtiger?
14:19:10 IceMichael: ne, es ist 13+25 + 13+23 + ...
14:19:19 IceMichael: ok, also (,) kann man natürlich auch so denken
14:19:38 Schrompf: ne, es ist ErsteVonDreizehn*25 plus ZweiteVonDreizahn*23 plus...
14:19:49 Schrompf: für zwei karten
14:19:55 IceMichael: ja genau
14:19:56 Schrompf: egal, ich muss los. bis denne
14:20:01 IceMichael: laters
16:06:08 IceMichael: tja, wenn ich die Hände der zwei Spieler so aggregiere, hab ich leider immer noch 4 Mrd. für alle möglichen Flops. Bringt also leider auch nix
16:08:16 IceMichael: obwohl, bisschen geht noch...
16:42:36 IceMichael: verdammt, es ist immer noch 1,2 Mrd. Einträge
16:42:57 IceMichael: also selbst wenn man berücksichtigt, dass alles in einer Suit dann nur 13*12*11*10*9*8*7 Möglichkeiten lässt
16:43:35 IceMichael: und bedenkt, dass Hand1 und Hand2 kommutativ sind
16:44:00 IceMichael: schade, war ne echt nette Idee, aber DAVON bräuchte ich ca. noch Faktor 5-10
18:04:43 Magister joined the channel
19:09:19 Schrompf joined the channel
19:41:34 Biolunar joined the channel
20:27:51 IceMichael: BUM. Also rainbow-Boards kann ich jetzt mit maximal 37 Regeln erschlagen
20:28:03 IceMichael: wovon eben immer unterschiedlich viele genommen werden. Das schöne ist: keine ist jemals falsch, manche sind nur "leer"
20:29:41 IceMichael: also ich kann pro Hand1 vs Hand2 halt auf jedem Rainbow-Board (auch paired) immer bis zu 37 Regeln anwenden, habe also quasi 37 Buckets maximal. 37/256... wirkt wenig, aber manchmal sind es halt auch 10 Buckets, die alles capturen
20:29:49 IceMichael: hm, vielleicht bringt's nachher auch nix, mal sehen
21:07:18 IceMichael: und dann kann ich noch Boards zusammenfassen
21:07:29 IceMichael: puh, das wär's dann... noch viel zu tun, aber es könnte klappen
21:07:46 IceMichael: leider ist two-tone wesentlich komplizierter als rainbow
21:31:32 IceMichael: das ist aber alles innerhalb eines Boards. Und dann kann ich noch die Suit-Permutations-Regel über mehrere Boards anwenden, um noch mehr zusammenzufassen
21:31:49 IceMichael: das multipliziert könnte es echt klein machen