J’ai appris les règles a ce moment la, et bricolé un goban en tissus, puis tout laissé tombé en moins d’un mois faute de partenaires.

J’ai repris cet été, et je passe mon temps a jouer sur Internet (KGS, IGS et wBaduk de temps en temps). Je pense que je suis bien accroc ce coup-ci.
Et pour boucler la boucle, je viens d’écrire un petit programme afin de comprendre comment ceux-ci peuvent fonctionner, a partir d’un algorithme de référence (je n’ai rien inventé).

Je vais essayer de le décrire ici.

Le programme de référence

Le programme de référence (jrefgo) utilise la méthode Monte-Carlo avec une évaluation en All Moves As First (AMAF).

Et si vous avez compris cette phrase, vous n’avez pas besoin de lire cette note, puisque c’est précisément ce que je vais tenter d’expliquer.

Ce programme a l’avantage d’être concis : une classe pour GTP (Go Text Protocol), un lanceur, et une classe principale qui gère tout le reste.

Malheureusement, il n’est pas aussi clair qu’il le pourrait, les variables ont des noms abscons, il y a des manipulations de bits qui ne sont pas forcément nécessaires, et beaucoup d’attributs utilisés comme des variables globales. Il reste néanmoins une bonne base, et je me suis plus ou moins contenté de le réarranger a ma sauce, sans en changer le fonctionnement.

Attention: je suis un développeur, pas un statisticien, il est donc possible que j’ai introduit des erreurs ou mal compris un point. N’hésitez pas a me corriger si vous voyez une bourde.

Pourquoi le jeu de go est difficile pour un ordinateur

Pour la plupart des jeux de stratégies de ce type, une intelligence artificielle est composée de deux éléments principaux :

• un arbre des coups possibles pour chaque joueur
• une fonction d’évaluation d’une position donnée

A partir de la, on peut évaluer les positions obtenues après X coups, et prendre le coup qui amène a la meilleure de ces positions.

Cette méthode n’est pas applicable au go pour deux raisons :

• le nombre de coups possibles est gigantesque, il n’est pas possible de générer un arbre d’une profondeur acceptable
• il est très dur d’évaluer une position (Ce territoire est-il définitif ? Ce groupe est-il vraiment vivant ? Combien vaut cette influence ? Et la pierre en bas, elle est morte, mais a-t-elle encore du potentiel ?)

Il a donc fallu trouver un autre angle d’approche.

La méthode Monte-Carlo

L’idée est assez simple, et je suis moi-même étonné de voir qu’elle fonctionne aussi bien :
puisqu’on n’est capable d’évaluer une position qu’en fin de partie, il suffit de la finir !

Ben oui, mais comment ? En jouant des coups au hasard. C’est ce qu’on appelle un “playout”. Ça fait une fin de partie absolument non réaliste, et peu fiable.
Mais si on joue 10 000 playouts ou plus, on commence a avoir des résultats intéressants. C’est une approche probabiliste.

En divisant le nombre de victoires par le nombre de playouts, on obtient une probabilité de victoire, le winrate. Le score ne compte pas vraiment, gagner de 0.5 ou de 30 points n’a pas d’importance. Si une position a un winrate > 0.5, la position est favorable, et inversement.

Corolaire : le coup qui amène a une position ayant le meilleur winrate est probablement le meilleur coup.

All Moves As First

Reste a savoir comment on mémorise le winrate pour chaque coup ou position. L’approche AMAF, c’est de ne pas tenir compte de l’ordre des coups, et juger toutes les pierres jouées entre la position initiale et la position finale. Par exemple, si 50 coups sont joués entre la position pour laquelle on veut trouver un coup, et la fin d’un playout, on comptabilise une victoire pour chacun des coups qui ont été joués.

L’avantage de cette méthode est le stockage du résultat : un tableau de la taille d’un goban suffit, avec un score pour chaque case. On obtient le meilleur coup après
simulation de toutes les fins de parties en parcourant ce tableau, et en conservant le coup avec le meilleur winrate.

L’inconvénient majeur de cette méthode est que le coup ayant le plus de chance de marcher contre un adversaire jouant au hasard n’est pas forcément le meilleur coup.
Un humain ne rate pas un simple shicho et ne se met pas en auto-atari en espérant que son adversaire l’ignore…

Implémentation

Il nous faut certaines fonction de base que je ne décrirais pas en détail, mais dont vous pouvez voir le source :

• une structure contenant une position (classe Board)
• un moyen d’avoir le score d’une position finale (classe Scorer)
• un moyen de vérifier la validité d’un coup et de le jouer (classe MoveManager)

Une fois qu’on a ces éléments, on peut rentrer dans le cœur du problème : la génération des playouts, les statistiques, et enfin la sélection du coup a jouer.

Génération d’un playout
CODE: McAmafGenerator.playout

1. on récupère la liste des intersections libres
2. tant qu’il reste des intersections libres, on en sélectionne une au hasard qu’on déplace pour ne pas la resélectionner plus tard
3. si l’intersection est valide, on la joue pour le joueur courant, sinon on recommence la sélection avec un autre coup
4. si le coup capture des pierres adverses, on récupère a nouveau la liste des intersections libres et on recommence au début, avec la position actuelle
5. lorsqu’il ne reste plus de coup valide, on passe. Après 2 passes consécutives, la simulation est terminée
6. on regarde qui gagne la partie dans la position finale, et on sauve les statistiques

Sauvegarde des statistiques après chaque playout
CODE: McAmafGenerator.trackStatistics

Pour chaque coup joué dans le playout par le joueur pour lequel on veut trouver un coup :

1. vérifier qu’il n’a pas déjà été joué avant depuis la position initiale, par aucun des deux joueurs
2. s’il n’a pas encore été joué, ajoute 1 ou -1 au score du coup selon le résultat final de la partie, et incrémente le nombre de simulations contenant ce coup.

L’ordre des coups n’a pas d’importance, mais on ne compte chaque coup qu’une seule fois au maximum par playout.

Sélection du coup a jouer
CODE: McAmafGenerator.generateMove

1. on remet les statistiques a zéro pour ne pas être influencé par les résultats des évaluations précédentes
2. on joue plein de playouts aléatoires
3. on récupère la liste de toutes les intersections du goban, qu’on mélange pour ne pas avoir toujours le même ordre de sélection en cas de winrates identiques
4. on récupère le winrate pour chaque intersection, si elle correspond un coup légal qui ne remplit pas un de ses propres yeux. S’il est meilleur que celui du coup actuellement sélectionné, on sélectionne le coup correspondant
5. s’il n’y a aucun coup légal restant, on passe
6. si le winrate de la position de départ est vraiment trop faible, on abandonne.

Pour aller plus loin

Les programmes de ce types évoluent généralement de deux façons :

• en conservant l’ordre des coups dans un arbre (ex: UCT)
• en ne faisant pas des playouts totalement aléatoires, mais plus plausibles (heavy playouts), en utilisant des heuristiques basées sur de la reconnaissance de forme.

Liens sur le sujet

Sur Wikipedia :
http://fr.wikipedia.org/wiki/Jeu_de_go_(informatique)

Le programme de référence :
http://cgos.boardspace.net/public/javabot.zip

Un port dans le langage “Google Go” :
http://github.com/skybrian/Gongo

Archives de la liste Computer-Go :
http://groups.google.com/group/computer-go-archive

Mon source :
http://bitbucket.org/vfiack/weiqibot/

Pages sur Sensei’s Library :
http://senseis.xmp.net/?ComputerGoAlgorithms
http://senseis.xmp.net/?MonteCarlo
http://senseis.xmp.net/?UCT

Un PDF sur les valeurs intéressantes :
http://www.fun.ac.jp/~kishi/pdf_file/AAAI06YoshimotoH.pdf

Je connaissais déjà la nyckelharpa, cet instrument suédois dont le spécialiste régionnal est Jean-Claude Condi, mais je ne l’avais jamais entendue avec un son si propre. Par moments, on a du mal a croire qu’il n’y a qu’un seul musicien sur scène.

Cet article est protégé par mot de passe. Pour le lire, veuillez saisir votre mot de passe ci-dessous :

Mot de passe :

C’est une œuvre pour laquelle nous n’avons pas de manuscrit autographe, mais uniquement des manuscrits de copistes (un par Anna Magdalena, sa seconde épouse, et deux autres que je n’ai jamais vu). Ces manuscrits ne sont pas forcément d’accord entre eux, que ce soit sur les liaisons ou même sur les notes, et on arrive donc a des éditions modernes qui comportent des différence.

Pour ce qui me concerne, voici l’extrait du manuscrit d’Anna Magdalena:

La dernière double croche de la ligne n’est pas très lisible. L’édition que j’utilise m’indique un la, celle de mutopia indique un sol.

Laquelle détient la vérité ?

ANTLR, c’est beaucoup plus classique : une grammaire dans un langage particulier, et on génère le code du parser a partir de cette grammaire. Son gros point fort, c’est ANTLRWorks, un chouette outil d’édition et surtout de débug de grammaires. C’est encore perfectible, surtout au niveau de l’ergonomie, mais ça remplit son office.

Le document à parser :

{abc|123|tralala}
{cde||youpie|tsoin tsoin|}

Chaque ligne est une étiquette, le nombre de champs est variable, et les champs vides sont autorisés. On veut récupérer un arbre :

1
2
3
4

grammar Etiquettes;
 
options { output=AST; }
tokens { ETIQUETTE; FIELD; }

Par convention, les tokens arbitraires sont tout en majuscules, les règles du lexer commencent par une majuscule, et les règles du parser par une minuscule. La règle principale s’appelle expr, et décrit l’ensemble du document.

La liste des tokens que le lexer doit repérer est assez claire :

5
6
7
8
9

Opening	:	'{';
Closing	:	'}';
Separator:	'|';
EndOfLine :	'n';
Text	:	~(Separator | Opening | Closing | EndOfLine)+;

Le texte, c’est tout ce qui n’est pas autre chose. J’imagine qu’il doit y avoir un moyen plus simple de le spécifier, mais je ne l’ai pas trouvé.

A partir de cet ensemble de tokens, on peut enfin construire notre document :

10
11
12

expr	:	etiquette+;
etiquette:	Opening field (Separator field)* Closing EndOfLine? -> ^(ETIQUETTE field+);
field	:	Text? -> ^(FIELD Text?);

On veut toujours parser une ou plusieurs étiquettes.
Une étiquette est construite à partir d’une ouverture, puis d’un ensemble de champs, d’une fermeture, et optionnellement d’une fin de ligne. Ce qui suit les flèches (->), c’est ce qu’on veut remonter dans l’arbre.

Avec tout ça, on peut enfin lancer le débugger d’ANTLRWorks sur notre petit document, et on obtient ceci :

Il reste encore a récupérer l’arbre coté Java, mais c’est assez simple.

Si je voulais comparer avec ma version précédente utilisant jparsec, ça prends plus de code, ça demande une génération de code + parcours manuel de l’arbre, mais c’est plus clair. Je n’ai pas comparé les performances.

Je pense que pour des documents plus complexe, je préfèrerais utiliser ANTLR, c’est plus simple a tester.

Un des points que j’aime bien, c’est la définition d’un château. Dans Monarques, c’est tout simplement une série de cases adjacentes, qui peuvent recruter des unités. Il faut pouvoir vérifier si deux cases font partie d’un même château, afin d’éviter que deux armées débutent au même endroit.

Les variations qui suivent sont bâties sur un principe identique :

• on part d’une case (x, y)
• si c’est une case d’un château, et que le château en cours de construction ne la contient pas déjà, on l’ajoute
• et on récurse sur les cases voisines

Variation impérative / objet
La première que j’ai écrite. Très simple, mais un peu laid, au niveau de la récursion sur les cases adjacentes. Peut mieux faire.

public class Castle
{
	private Map map;
	private Collection elems;
 
	protected Castle(Map map, int x, int y)
	{
		this.map = map;
		this.elems = new ArrayList();
 
		MapElement elem = map.getElementAt(x, y);
		buildCastle(elem);
	}
 
	private void buildCastle(MapElement elem)
	{
		if(elem == null || !elem.canRecruitUnits() || elems.contains(elem))
			 return;
 
		elems.add(elem);
 
		Coordinates coord = elem.getCoordinates();
		buildCastle(map.getElementAt(coord.getX()-1, coord.getY()-1));
		buildCastle(map.getElementAt(coord.getX()-1, coord.getY()));
		buildCastle(map.getElementAt(coord.getX()-1, coord.getY()+1));
		buildCastle(map.getElementAt(coord.getX(), coord.getY()-1));
		buildCastle(map.getElementAt(coord.getX(), coord.getY()+1));
		buildCastle(map.getElementAt(coord.getX()+1, coord.getY()-1));
		buildCastle(map.getElementAt(coord.getX()+1, coord.getY()));
		buildCastle(map.getElementAt(coord.getX()+1, coord.getY()+1));
	}
}

Variation fonctionnelle
J’ai gardé le type de données, les conditions d’arrêt sont identiques. La récursion est un peu plus complexe a cause du foldl, mais on a une liste de cases adjacentes plutôt que du code dupliqué, c’est toujours ça de pris.

data Castle = Castle { castleCoords :: [Coords] }
 
buildCastle :: Map -> Castle -> Coords -> Castle
buildCastle m c xy
  | not (canRecruitUnits m xy) = c
  | xy `elem` (castleCoords c) = c
  | otherwise = foldl (buildCastle m) c' (near xy)
  where
    c' = Castle (xy:(castleCoords c))
    variations x = [x-1, x, x+1]
    near (x, y) = [(a, b) | a <- variations x, b <- variations y, (a, b) `isInMap` m && (a, b) /= (x, y)]

Variation simplifiée
La dernière en date. Finalement, je n’ai pas besoin de type de données particulier, vérifier si les deux coordonnées sont dans la liste qui constitue un château me suffit. J’ai repris l’idée de la liste des cases adjacentes (growable), mais l’itération dessus me semble plus claire que le foldl.

class Board:
  #...
  def buildCastle(self, x, y, accumulator):
    if (x, y) in accumulator or not self.isCastleArea(x, y):
      return accumulator
 
    accumulator.append( (x, y) )
    growable = [(a, b) for a in (x-1, x, x+1)
                       for b in (y-1, y, y+1)
                       if self.isInBoard(a, b) and not (a, b) in accumulator]
    for x, y in growable:
      self.buildCastle(x, y, accumulator)
    return accumulator

On a un document très simple à parser :

{abc|123|tralala}
{cde||youpie|tsoin tsoin|}

On veut évidement récupérer des listes de chaines, sans se poser de question. Tellement simple qu’on pourrait le faire a la main. Mais voilà, moi, j’avais envie d’essayer JParsec, et tous les exemples sont terriblement plus compliqués (et surtout, plus orientés langages et opérations).

L’idée de parsec, c’est de faire des parsers directement dans le langage du programme, et de les combiner, plutôt que de rédiger une grammaire qui sera convertie (genre antlr). Ce qui me plait la dedans, c’est l’impression de pouvoir y aller progressivement.

Bref.

L’essentiel du boulot est dans la classe Scanners. Pensez à regarder les méthodes, et pas que les champs, c’est ce qui m’a foutu dedans ce matin (on va dire que j’étais fatigué).

Donc pour éviter d’avoir a préfixer tout ce qu’on va appeler :

1

import static org.codehaus.jparsec.Scanners.*;

Et on combine. Commençons par ce qu’on veut récupérer, c’est a dire les caractères entre les pipes :

1

Parser<String> content = notAmong("|}").many().source();

La méthode source(), c’est l’astuce pour récupérer le texte qui matche. Je ne comprends pas pourquoi ces parseurs ne renvoient pas la chaine directement.

Une fois qu’on a cette chaine, on peut récupérer une liste, puis la ligne complète :

2
3

Parser<List<String>> enclosed = content.sepBy(isChar('|'));
Parser<List<String>> line = enclosed.between(isChar('{'), isChar('}'));

Il ne nous reste plus qu’a boucler sur les lignes :

4
5
6

Parser<Void> eof = (Parser<Void>)Parsers.EOF; 
Parser<Void> endOfLine = among("rn").or(eof);
Parser<List<List<String>>> lines = line.endBy(endOfLine);

Et voilà, on y est :

7

System.out.println(lines.parse(document));

=> [[abc, 123, tralala], [cde, , youpie, tsoin tsoin, ]]

Résultat des opérations : 6 lignes de code pour récupérer des données structurées.