Hi!
Also: Ich habe die Sache natürlich auch nur in engen Grenzen verstanden, aber man kommt dem Kern noch näher, wenn man sich überlegt, welche Konzepte man in "sein" Programm implementieren sollte und wie die Umsetzung desselben aussieht. - Was kommt dann am Ende raus?
Es nützt nichts, hier zu spekulieren, solange die Spielregeln nicht klar sind.
Die Spielregeln:
100 Teilnehmer, jeder spielt gegen jeden eine Serie von n Spielen, wobei n>1000, es gibt in jedem EinZelspiel einen Punkt zu gewinnen oder verlieren. Es gibt m Preise, wobei m <=5. Preise werden vergeben an die Punktbesten.
Die Programme kennen sich vor dem Turnier nicht (es sei denn von fruehren Turnieren).
Absprachen unter den _Programmierern_ (nicht unter Programmen _waehrend des Turniers_) sind verboten. (Mogelmoeglichkeiten sind m.E. fuer diese Diskussion auch nicht von Interesse.)
Was sinnvoll ist, wenn's darum geht, ein Programm zu schreiben, welches möglichst viele SSP gewinnen soll, habe ich lang und breit beschrieben.
Du hast lang und breit beschrieben, was Du fuer sinnvoll haeltst.
Was man hingegen tun sollte, wenn das Spiel kein faires Spiel sondern ein kooperativ manipuliertes Spiel sein soll, hängt ultimativ davon ab, wie die Regeln lauten, und welche weiteren Kommunikationsmöglichkeiten die Programme haben - ob z.B. die Kommunikation nur über Stein-Schere-Papier-Auswahl laufen darf, und ob es für diese Kommunikation eine vereinbarte Sprache gibt.
Finde die Regeln - dann gehts hier weiter!
Das Spiel ist fair und m.E. ein Kooperastionstest fuer soziologisch interessierte Entwickler.
Das letzte Tunrier wurde von einem Programm gewonnen, das Mustererkennung macht und blockweise (also z.B. in einem Einzelmatch nach n/10 Spielen) sein Verhalten aendert (wie ist mir nicht bekannt).
Die Kommunikation geht ueber das Protokoll namens Papier - Stein - Schere'. Das ist kein binaeres Datensendensondern eintertiaeres Datensenden`.
Gruss,
Luddie