Il suppose une machine avec un ruban de mémoire, un pointeur sur une cellule de cette mémoire, et ne contient que 8 opérations, chacune représentée par un caractère dans le code source :

En résumé, > et < font bouger un pointeur, + et - modifient la valeur de la cellule courante, . et , servent d'entrées-sorties, et [ ] fait une boucle.

A titre d’exemple, ce programme affiche “Hello World!” : hello.bf

Voici le code complet de l’interpréteur que cet article vise a expliquer.

Interpréteur basique, sans optimisations

Représentation des opérations basiques de BrainFuck

La première chose à faire, c’est de décider de la représentation interne des opérations. J’ai choisi de regrouper les opérations de déplacement et de modification, et de représenter [..] comme une sous liste d’opération.

  type operation =
    | Move of int 
    | Add of int
    | Output
    | Input
    | Loop of operation list

Conversion du code BF en arbre d’opérations

Maintenant, il nous faut un moyen de convertir le source BrainFuck en un arbre d’opérations, en utilisant le type que nous venons de définir. En dehors des boucles, la conversion est assez directe.

  let rec build_ast tokens =
    let rec loop tokens acc =
      match tokens with
      | [] -> acc
      | '>' :: rest -> loop rest (Move 1 :: acc)
      | '<' :: rest -> loop rest (Move (-1) :: acc)
      | '+' :: rest -> loop rest (Add 1 :: acc)
      | '-' :: rest -> loop rest (Add (-1) :: acc)
      | '.' :: rest -> loop rest (Output :: acc)
      | ',' :: rest -> loop rest (Input :: acc)
      | '[' :: rest ->
          let sublist, rest = build_loop tokens in
          let cond = build_ast sublist in
          loop rest ((Loop cond) :: acc)
      | ']' :: rest -> failwith "Close should have been consumed by build_loop"
      | _ :: rest -> loop rest acc
    in
    List.rev (loop tokens [])

Je n’ai pas cité la fonction build_loop pour des raisons de place, mais elle est disponible dans le source complet.

Interprétation dans une machine virtuelle basique, avec sa mémoire fixe et son unique pointeur

Voilà notre arbre d’opérations, il nous reste à l’exécuter.

On utilise une “machine virtuelle”, avec sa mémoire et son pointeur :

  let memory = Array.make 30_000 0
  let pointer = ref 0

Par simplification, la mémoire est limitée a 30000 cellules, sous forme de tableau plutôt que de ruban.

Les fonctions de base, qui correspondent aux opérations de BF :

  let move i = pointer := !pointer + i
 
  let add i = memory.(!pointer) <- memory.(!pointer) + i
 
  let output () = Printf.printf "%c%!" (char_of_int memory.(!pointer))
 
  let input () =
    let c = input_char stdin in
    memory.(!pointer) <- int_of_char c

Et enfin, l’exécution d’une liste d’opérations, obtenue à partir du source BF.

  let rec exec ast =
    let exec_node = function
      | Move i -> move i
      | Add i -> add i
      | Output -> output ()
      | Input -> input ()
      | Loop nodes ->
          while memory.(!pointer) <> 0 do
            exec nodes;
          done
    in
    List.iter exec_node ast

L’interprete basique est terminé. Il n’est pas particulièrement rapide, mais il fonctionne.

Voyons comment améliorer tout ca.

Optimisations simples

Il est possible de faire une optimisation simple, sans changer notre type opération et en conservant la structure du programme a l’identique.

Regroupement d’opérations similaires
Avec une traduction simple, “+++” devient [Add(1);Add(1),Add(1)]. En les regroupant, on peut n’avoir qu’une seule instruction, Add(3). La même chose est possible pour les instructions Move.

  let rec group = function
    | Move a :: Move b :: rest ->
        let lst = if a + b <> 0 then Move (a + b) :: rest else rest in
        group lst
    | Add a :: Add b :: rest ->
        let lst = if a + b <> 0 then Add (a + b) :: rest else rest in
        group lst
    | Loop a :: rest -> (Loop (group a)) :: (group rest)
    | other :: rest -> other :: (group rest)
    | [] -> []

Et tant qu’a faire, on se débrouille pour ne pas conserver de Add(0), ce qui serait un peu dommage.

Optimisations avancées

On a besoin d’ajouter un type macro, et un constructeur Macro au type “operation” défini précédemment

  type macro =
    | Set of int * int
    | AddMultToCell of int * int
    | AddMultToCell2 of int * int * int
    | CopyMultToCell of int * int
    | AddTo of int * int
 
  type operation =
     ...
     | Macro of macro

Voici ce qu’elles représentent :

Les programmes BrainFuck contiennent fréquemment des séquences similaires, que nous allons remplacer par ces macros.

Remplacement de boucles courantes par des macros

Commençons par les boucles. Celles-ci sont :

Passer de la boucle a sa signification sémantique, puis sa macro, n’est pas forcément évident.
Si vous ne voyez pas le lien entre la boucle et sa description, ca peut valoir le coup de creuser.

Une fois la relation entre les opération brainfuck et ce que le programme essaye d’accomplir établie, on peut enfin les remplacer par nos macros.

  let rec unroll ast =
    let replace = function
      | [Add (-1)] -> Macro (Set (0, 0))
      | [Move a; Add n; Move b; Add (-1)]
      when a = - b -> Macro (AddMultToCell (n, a))
      | [Move a; Add n1; Move b; Add n2; Move c; Add (-1)]
      when a + b = - c && n1 = n2 -> Macro (AddMultToCell2 (n1, a, a + b))
      | [Macro (Set (n, i)); Add (-1)] -> Loop [Macro (Set (n, i)); Macro (Set (0, 0))]
      | other -> Loop (unroll other)
    in
    match ast with
    | Loop ops :: rest -> replace ops :: unroll rest
    | other :: rest -> other :: (unroll rest)
    | [] -> []

Exécution directe, sans déplacement préalable
C’est bon pour les boucles, mais il reste d’autres séquences qu’on peut réduire.

On retrouve souvent la séquence [Move i, Action, Move -i]. Si on peut le remplacer par une action distante, on gagne deux déplacements.

  let in_place ast =
    let rec loop = function
      | Move i :: Add n :: Move j :: rest
        when i = - j -> Macro (AddTo (n, i)) :: loop rest
      | Move i :: Add n :: Move j :: rest -> 
        Macro (AddTo (n, i)) :: loop (Move (i+j) :: rest)
      | Move i :: Macro (Set (n, j)) :: Move k :: rest 
        when i = -k -> Macro (Set (n, i)) :: loop rest
      | Loop ops :: rest -> Loop (loop ops) :: loop rest
      | other :: rest -> other :: loop rest
      | [] -> []
    in loop ast

Et voila le travail.

Retour sur les regroupements
On avait déjà regroupé les Add et Move (c’était notre première optimisation).
Il est aussi possible de regrouper les opérations impliquant nos macros, dans une deuxième passe.

  let rec group = function
    ...
    | Add a :: Macro (Set (n, 0)) :: rest -> group (Macro (Set (n, 0)) :: rest)
    | Macro (Set (_, i)) :: Macro (Set (n, j)) :: rest 
      when i = j -> group (Macro (Set (n, j)) :: rest)
    | Macro (Set (n, 0)) :: Add a :: rest -> group (Macro (Set (n+a, 0)) :: rest)
    ...

Et notre optimisation va s’arreter ici. Il reste possible de faire d’autres macros pour d’autres séquences communes, mais cela n’apporterait pas grand chose d’un point de vue pédagogique.

Le résultat

Le code complet de l’interpreteur.
Le programme benchmark, qui calcule des nombres premiers : prime.bf

Sans optimisation

$ time (echo 99 | ./brainfuck.native prime.bf)
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 

real	0m1.871s
user	0m1.868s
sys	0m0.000s

Avec optimisations

$ time (echo 99 | ./brainfuck.native -optimize prime.bf)
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 

real	0m0.064s
user	0m0.056s
sys	0m0.004s

En gros, ca va 30x plus vite. Si seulement tout pouvait s’optimiser aussi facilement !

A vous de jouer

Grace au projet js_of_ocaml, j’ai pu porter le compilateur en javascript. Il est utilisable ici.

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.