Forum du club des d�veloppeurs et IT Pro - Blogs - Func' programming - un blog hom�opathique par stendhal666

SFINAE Interlude - C++ avanc�

stendhal666 — Wed, 06 Jan 2016 15:03:29 GMT

Dans le billet pr�c�dent, nous avons utilis� une assertion statique. Ces assertions sont faites lors de la compilation : si elles �chouent, le programme ne compile pas et � et c'est l� l'int�r�t principal � le compilateur affiche un message clair, que vous avez d�fini, plut�t qu'une longue suite d'erreurs template illisibles. La STL C++11 d�finit un certain nombre de conditions qui peuvent �tre utilis�es dans une expression static_assert. std::is_same est l'exemple que nous avons utilis� pour v�rifier que l'it�rateur fourni � la fonction scanpattern �tait bien un std::random_access_iterator. Il arrive un point, cependant, o� l'on doit d�finir soi-m�me la condition de l'assertion statique.

Is it a good processor ?
Prenons une fonction mineTree, par exemple, qui prend pour argument un Processor qui doit poss�der un op�rateur de fonction applicable � un std::pair, int> (c'est la forme des frequent patterns). Il n'existe pas de condition standard qui permette de v�rifier cela et il va falloir cr�er la n�tre.

La signature de notre condition sera : template has_func_operator.
Nous pourrons l'utiliser de la fa�on suivante :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
static_assert(has_func_operator, int>>::value,
                   "Bad Processor Error: Processor must implement func operator with signature operator()(Arg)");
au d�but de la fonction mineTree.

Qu'est-ce qu'une condition statique ?
static_assert exige une condition statique, c'est-�-dire une condition qu'il est possible de v�rifier � la compilation. Il est donc impossible d'�crire, par exemple :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
char c;
std::cin >> c;
static_assert(c == 'a', "erreur: c != a"); // c'est déterminé à l'exécution !
Donc toute la difficult� de l'exercice est d'obtenir l'information sans entrer dans un contexte d'ex�cution, appel� aussi contexte d'�valuation. Prenons l'exemple de la condition std::is_same, comment peut-elle �tre impl�ment�e ? Assez simplement, en fait, m�me avec les versions plus anciennes du standard : on utilise la possibilit� de sp�cialisation partielle des templates, processus qui se d�roule enti�rement � la compilation :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
template <class T, class U>
struct is_same {
  static const bool value = false; // T et U sont des types différents
};
template <class T>
struct is_same { //, mais là T et U sont le même type!
  static const bool value = true; // donc is_same::value = true
};
H�las, tout n'est pas si simple
Certaines conditions sont plus difficiles � v�rifier que d'autres. Celle que nous recherchons, has_func_operator, ne peut pas �tre impl�ment�e uniquement avec les sp�cialisations partielles. On peut de cette fa�on v�rifier le type d'une fonction, mais pas son existence : pour que la sp�cialisation fonctionne, il faut qu'au moins une des sp�cialisations soit valide. Il faut trouver une fa�on d'utiliser le contexte de compilation d'une fa�on que l'erreur devienne constructive � et c'est exactement le r�le de cette technique nomm�e SFINAE.

Substitution failure is not an error
L'�chec d'une substitution n'est pas une erreur. D�cortiquons cela :
l'�chec d'une substitution : pour instancier une fonction template surcharg�e (avec plusieurs signatures), le compilateur regarde les diff�rentes signatures possibles et choisit celle qui est la plus adapt�e. C'est le principe de la substitution : on substitue � une signature g�n�rique une signature d�termin�e.
n'est pas une erreur : vous me direz que c'est la m�me chose pour une fonction normale, sans template : certes, mais avec une diff�rence importante : si une des fonctions normales qui peut �tre choisie est mal form�e, le compilateur refusera de compiler. Ce n'est pas le cas lorsqu'il s'agit d'une fonction template. Pourquoi ? Parce qu'une fonction template qui n'est pas appel�e n'est pas instanci�e. Pour le compilateur, elle n'existe pas. Donc si elle est mal form�e, peu importe -> l'�chec d'une substitution n'est pas une erreur.

Concr�tement, comment �a marche ?
Comme une fonction template qui n'est pas retenue lors de l'�tape de substitution n'est pas instanci�e, deux fonctions de m�me nom peuvent �tre surcharg�es aussi bien du c�t� des arguments que du c�t� du type de retour. En examinant le type de retour, on peut donc savoir quelle surcharge a �t� appel�e. C'est ainsi qu'on utilisait SFINAE dans les versions du standard ant�rieures � C++11. Par exemple, voici une astuce pour d�terminer si un type est une classe. Elle repose sur le fait qu'une signature comportant un pointeur sur un membre non statique d'un type provoquera un �chec de substitution si le type n'est pas une classe :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
typedef char is_a_class[2]; // on différencie les types de retour par leur taille
typedef char is_not_a_class; // on est au moins sûr que sizeof(char) == 1
template <class T> is_a_class func(int T::*); // pointeur sur un membre int - cette signature sera utilisée si T est une classe, sinon elle échouera...
template <class T> is_not_a_class func(...);    // ...et c'est cette signature qui sera utilisée.
La moiti� du chemin
Nous avons fait la moiti� du chemin, reste la deuxi�me. Comme vous pouvez le constater, les signatures de func ci-dessus ne sont pas d�finies. Ce n'est pas g�nant, car nous devons rester en dehors du contexte d'�valuation ou d'instanciation. Avant C++11, le moyen de rester dans ce contexte �tait offert par l'op�rateur sizeof. C'est la raison pour laquelle j'ai pris deux types de retours dont on peut �tre certain qu'ils sont de tailles diff�rentes. Nous allons pouvoir encapsuler notre r�solution de substitution et r�soudre la question de la surcharge retenue :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
template <class T>
struct is_class {
// comme avant
typedef char is_a_class[2];
typedef char is_not_a_class; 
template <class T> is_a_class func(int T::*); 
template <class T> is_not_a_class func(T);
// et on rajoute
static const int value = sizeof(func(0)) == sizeof(is_a_class); // static const: on reste dans le contexte de compilation tant qu'on ne prend pas l'adresse de value (légère simplification)
};
De retour au processeur et � C++11
L'impl�mentation de SFINAE qu'on a vue est tr�s astucieuse, mais c'est de l'histoire ancienne. C++11 offre des ressources plus puissantes pour la m�taprogrammation. C'est avec ces ressources nouvelles que nous r�soudrons la question initiale, l'�criture de has_func_operator. En voici le code, l'explication vient :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
// 1
template <class T, class Arg>
auto constexpr has_func_operator_intern(int) -> decltype(std::declval()(Arg()), bool()) {
  return true;
}
// 2
template <class , class>
bool constexpr has_func_operator_intern(...) {
  return false;
}
// 3
template <class T, class Arg>
struct has_func_operator {
  static const bool value = has_func_operator_intern(0);
};
Nous commen�ons par la deuxi�me fonction :

c'est une fonction constexpr : c'est-�-dire que, sous r�serve que son contenu le permette, elle peut-�tre appel�e � la compilation, donc en dehors d'un contexte d'ex�cution ;
elle a pour signature l'ellipse (...) : au moment de la substitution, c'est la signature qui a la priorit� la plus faible ; elle ne sera utilis�e que si toutes les autres substitutions ont �chou�.

La premi�re fonction est plus compliqu�e :

son type de retour est indiqu� apr�s la fl�che -> . C'est une nouvelle syntaxe de C++11: le mot-cl� auto est utilis� � la place du type de retour et pr�cis� apr�s la fl�che ;
son type de retour est le r�sultat de l'expression decltype ; comme sizeof, decltype reste dans le contexte de compilation. Elle retourne le type de l'expression donn�e en argument ;
l'argument de decltype est compos� autour de l'op�rateur virgule : ses deux op�randes sont �valu�s, mais c'est celui de droite qui est renvoy� ;
l'op�rande de droite initialise un bool ; decltype retournera donc le type bool de m�me que la fonction has_func_operator_intern ;
l'op�rande de gauche est complexe. Plus simplement on aurait pu l'�crire T()(Arg()), mais cela aurait pos� une difficult�: si T n'a pas de constructeur accessible, la substitution �chouera. Si T est une lambda, qui pourrait pourtant avoir un op�rateur de fonction comme on le recherche, la substitution �chouerait. C'est le r�le de std::declval de r�soudre ce probl�me.
std::declval() retourne une r�f�rence sur l'objet T, ce qui permet de l'utiliser � en dehors du contexte d'ex�cution �videmment, uniquement dans celui de la d�duction des types �pour appeler une fonction membre d'une classe sans avoir � invoquer son constructeur. Donc nous avons une r�f�rence sur un objet T inexistant qui nous permet d'appeler son op�rateur de fonction.

La troisi�me fonction est toute simple : c'est seulement une enveloppe autour des deux premi�res qui �vite d'utiliser directement SFINAE en �crivant :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
has_func_operator_intern(0);
dans le corps du programme. De plus, elle harmonise l'interface de notre condition statique avec l'interface des conditions propos�es par la STL.

En conclusion
Dans notre contexte, SFINAE n'a permis qu'une seule chose : g�n�rer un message d'erreur plus lisible si le Processor fourni n'a pas les fonctionnalit�s suffisantes. Mais ses possibilit�s sont nombreuses. � vous, maintenant que vous avez l'id�e en t�te, de faire preuve d'imagination ! Au fur et � mesure que vous entrerez dans les subtilit�s de SFINAE, vous d�couvrirez aussi les subtilit�s du C++ : savoir ce qui appartient au contexte d'�valuation (o� tout doit �tre d�fini) et au contexte de compilation (o� les d�finitions partielles sont permises) est une question byzantine. Vous pouvez jeter un �il sur cppreference pour d�broussailler le terrain. Vous verrez que tant qu'on reste en dehors de l'usage � odr � (comprendre one definition rule,) on reste dans les limites de ce qui peut �tre r�alis� � la compilation.

D�tection des associations fr�quentes en C++ - troisi�me partie: une interface digne de ce nom

stendhal666 — Mon, 04 Jan 2016 04:20:16 GMT

Apr�s avoir introduit l'algorithme de d�tection, j'en ai propos� une impl�mentation na�ve (1, 2). En partant de si bas, beaucoup d'am�liorations sont possibles avant d'en faire une impl�mentation de qualit�. Nous commencerons par proposer une interface compatible avec les exigences d'un d�veloppeur C++ client.

C'est une affaire de psychologie
Le d�veloppeur C++ aime la performance et il d�teste tout ce qui l'oblige � cr�er une structure de donn�es interm�diaire, � allouer de la m�moire. M�me copier un entier lui est d�sagr�able. L'�tat d'esprit du d�veloppeur Python est diff�rent: si je peux cr�er, pense-t-il, en 20 minutes, un programme qui s'ex�cute en 1 seconde, je fais un meilleur march� que si je mets 20 heures � cr�er le m�me programme qui s'ex�cute en 1 ms. Le d�veloppeur Python prend un plaisir particulier � �crire en deux lignes ce qui en prendrait 20 en C++. Pour cette raison, l'interface compte moins.

Reprenons le fil de notre algorithme: l'argument de la fonction buildTree est std::vector>; en python cela �quivaut � une liste de listes: [[]]. Pour convertir en liste de listes un fichier o� les transactions sont s�par�es par des retours � la ligne et les �l�ments des transactions par des espaces, il suffit d'�crire:
Code Python : S�lectionner tout - Visualiser dans une fen�tre � part
[[item for item in line.strip().split( )] for line in open("myfile.csv")]
Et je me sens intelligent, moderne. J'ai une pens�e entre amusement et piti� pour le d�veloppeur C++.

Pourquoi c'est mal, tentacule et csv
En �crivant cette petite ligne de code, on a d�montr� la concision de Python, certes. On a aussi copi� tout le fichier en m�moire, et on s'appr�te � copier tous les objets en m�moire une seconde fois dans l'arbre des associations fr�quentes. Quel d�veloppeur C++ digne de ce nom accepterait une chose pareille?

Je vous conseille la lecture d'un excellent article de white_tentacle qui porte sur la lecture d'un ficher csv en C++ et illustre bien cette exigence: pour travailler sur un fichier csv, il n'est pas toujours n�cessaire de le charger enti�rement en m�moire, loin de l�; il faut toujours charger le minimum possible: peut-�tre une ligne, peut-�tre m�me simplement une cellule. Le parseur de csv que white_tentacle propose demande de fournir deux fonctions de call back: une appel�e lorsqu'une cellule a �t� lue, une lorsqu'une ligne a �t� lue. S'il s'agit simplement d'afficher le fichier, par exemple, vous pourrez fournir une fonction qui affiche un �l�ment comme call_back de cellule, et une fonction qui affiche un retour � la ligne comme call_back de ligne. Empreinte m�moire? quasi-nulle.

Vous pouvez raisonner de la m�me fa�on pour une base de donn�es: vous n'allez pas charger en m�moire tous les enregistrements qui correspondent � votre requ�te avant de travailler dessus, sauf si cela est tout � fait n�cessaire; vous pr�f�rerez de travailler enregistrement par enregistrement, voire champ par champ, si cela est possible.

Une interface pour plaire � deux d�veloppeurs C++
Vous devez donc proposer comme interface des fonctions primitives: celles qui donneront le plus de libert� au d�veloppeur client pour conserver une performance maximale. Mais ce n'est pas tout: vous devez �galement choisir une interface qui vous donnera suffisamment de libert� pour am�liorer la performance de votre algorithme sans casser le code client. Il vous faut donc trouver le niveau de granularit� ad�quat: d'assez bas niveau pour laisser au client faire ses choix, d'assez haut niveau pour que vous puissiez modifier les v�tres. L'interface de d�part, c'est tout le contraire:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
  // une mauvaise interface
  // les fonctions pour construire la fp-tree
  bool buildTree(const std::vector>& input);
  bool buildTree(const std::vector, int>>& input);
  void scanSequenceForFrequency(const std::vector& input, int freq = 1);
  void deleteInfrequentItems();
  void scanSequenceIntoTree(std::vector& input, int freq = 1);
 
  //les fonctions pour chercher les associations fréquentes
  void mineTree(std::vector, int>>& patterns, const std::vector& prefix);
  std::vector ascendTree(fpnode* bottom);
  std::vector, int>> getConditionalPatterns(const Item& i);
Quelle interface pour la construction du frequent pattern tree?
Construire un arbre des associations fr�quentes, c'est 1) parcourir la liste des transactions pour conna�tre la fr�quence de chaque �l�ment et 2) parcourir � nouveau la liste des transactions pour int�grer chacune des transactions � l'arbre. Contrairement � ce que laissait penser l'interface initiale, ce sont deux �tapes h�t�rog�nes: dans un cas c'est l'�l�ment qui nous int�resse, dans le deuxi�me la s�quence.

La signature de scanFrequency doit donc se rapporter � un �l�ment, plus � une s�quence:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
 
  void scanFrequency(const Item& i, int freq=1);
La signature de scanPattern ne peut pas non plus rester telle qu'elle �tait: elle prenait comme argument non pas une s�quence mais une structure de donn�es qui la repr�sentait (le std::vector). Le moyen � privil�gier pour repr�senter une s�quence en C++, c'est l'it�rateur:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
  template <class RandomIterator>
  void scanPattern(RandomIterator b, RandomIterator e, int freq=1);
Il vaut mieux pr�ciser dans la signature quel type d'it�rateur est n�cessaire. Ici, comme l'algorithme de tri de la STL est utilis�, vous avez besoin d'un it�rateur permettant un acc�s al�atoire. Le nom du param�tre en template n'est qu'une indication -pr�cieuse- pour le client. Vous pouvez n�anmoins ajouter une assertion statique au d�but de la d�finition de la fonction pour g�n�rer un message d'erreur lisible lors de la compilation:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
template <class Item> // dans la définition d'une fonction template d'une classe template
template <class RandomIterator> // le template de la classe vient en premier
void fptree::scanPattern(RandomIterator b, RandomIterator e, int freq) {
  static_assert(std::is_same<
		     std::random_access_iterator_tag,
		     typename std::iterator_traits::iterator_category
		     >::value, "Bad pattern iterator: access must be random in scanPattern(Iterator, Iterator)");
(...)
Quelle interface pour extraire les frequent patterns?
La signature de mineTree pr�sente le m�me probl�me que celle de scanPattern: elle utilise une structure de donn�es (passablement compliqu�e en plus) pour repr�senter la s�quence des r�sultats.
Code : S�lectionner tout - Visualiser dans une fen�tre � part
void mineTree(std::vector, int>>& patterns, const std::vector& prefix);
N�anmoins, la solution est moins �vidente dans ce cas-l�, car il n'y a pas d'it�rateur qui soit � la fois assez g�n�ral et d'usage assez fr�quent pour repr�senter efficacement ce que la fonction attend de l'utilisateur. Mettons que l'on choisisse de nommer notre it�rateur InserterIterator, l'utilisateur pourrait penser que std::back_inserter, std::front_inserter et std::inserter, indiff�remment, vont fonctionner, ou bien il se demandera lequel est compatible. Il ne pensera pas n�cessairement � un std::ostream_iterator qui pourrait pourtant �tre un candidat valable. Enfin, r�aliser son propre it�rateur est une t�che qui, sans �tre bien compliqu�e, ne doit pas �tre impos�e � un client si elle n'est pas n�cessaire.

Vous me direz ce que vous en pensez: la solution la meilleure, � mon avis, est de demander � l'utilisateur de fournir quoique ce soit qui puisse �tre appel� comme une fonction: un foncteur, une fonction lambda, une simple fonction (ne les oublions pas!). J'ai donn� � ce "fonction-like" le nom de Processor:
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
  template 
  void mineTree(PatternProcessor& processor, const Prefix& prefix = Prefix());
Dans le corps de la fonction, au-lieu d'�crire:
results.push_back(std::make_pair(last_transaction, last_transaction_frequency));vous �crivez:
processor(std::make_pair(last_transaction, last_transaction_frequency));et c'est le seul changement.

Quelques exemples d'appel:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
 
  // pour affiche simplement le résultat à l'écran
  using Transaction = std::vector;
  using FrequentPattern = std::pairint>;
  auto processor = [](const FrequentPattern& pat) { // avec une lambda
    for (auto& i : pat.first) std::cout << i << ' ';
    std::cout << " : " << pat.second << std::endl;
  };
  fpt.mineTree(processor);
ou bien:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
 
  // pour remplir un vecteur
  using Transaction = std::vector;
  using FrequentPattern = std::pairint>;
  std::vector rc;
  auto processor = [&](const FrequentPattern& pat) { rc.push_back(pat); }
  fpt.mineTree(processor);
En r�sum�
L'interface de la classe fptree ressemble d�sormais � �a:
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
 
public:
  void scanFrequency(const Item& i, int freq=1);
  template <class RandomIterator>
  void scanPattern(RandomIterator b, RandomIterator e, int freq=1);
  template <class PatternProcessor>
  void mineTree(PatternProcessor& processor, const Prefix& prefix = Prefix()) const;
  void show();
J'ai gliss� sans le dire un const � la fin de la d�claration de mineTree. Un autre aspect important d'une interface C++ est de toujours pr�ciser si une m�thode modifie ou non la classe sur laquelle elle est appel�e. Le respect de cette convention nomm�e const-correctness permet au compilateur de faire du travail � notre place et, parfois, d'optimiser le code g�n�r�.

Seulement une �tape
Tout cela n'est bien s�r qu'une �tape dans le processus de raffinement de notre classe. Mais nous pouvons d�sormais continuer ce travail � l'abri d'une interface qui n'�nervera pas le d�veloppeur client et qui nous laisse une grande libert� pour modifier notre code.

Dans le prochain �pisode, vous mettrez vos mains dans le cambouis de la gestion m�moire...

D�tection des associations fr�quentes en C++ - deuxi�me partie

stendhal666 — Tue, 29 Dec 2015 09:55:58 GMT

Dans le billet pr�c�dent, vous avez vu comment construire l'arbre des associations fr�quentes, ou fptree. Vous verrez dans celui-ci comment utiliser l'arbre pour d�duire les associations fr�quentes, sans plus retourner � la base de donn�es initiale. Vous terminerez ainsi de d�couvrir cette premi�re impl�mentation na�ve et "pythonesque" de l'algorithme. Dans les prochains billets, il sera temps de la raffiner pour arriver � un r�sultat plus conforme � l'esprit du C++ et de ses standards r�cents.

Extraction des associations fr�quentes, le principe
Comme je le mentionnais en introduction, l'extraction des associations fr�quentes, quoique facile � encoder, est plus difficile � concevoir. Elle repose sur le principe suivant:

on commence par placer les �l�ments fr�quents de l'arbre, qui sont contenus dans la table des �l�ments, parmi les associations fr�quentes. En effet, ils constituent trivialement des associations fr�quentes;
pour chacun de ces �l�ments, en commen�ant par le moins fr�quent, on va construire r�cursivement un arbre de fr�quence conditionnel. Comment est-ce que cela fonctionne?

L'arbre de fr�quence conditionnel
L'arbre de fr�quence conditionnel d'un �l�ment de l'arbre initial est g�n�r� � partir des s�quences qui partent de chaque noeud contenant cet �l�ment. La s�quence commence � partir du parent de ce noeud et s'arr�te au dernier noeud avant la racine. Voici la fonction qui recherche, pour un noeud, la s�quence ascendante en question:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
template <class Item>
std::vector fptree::ascendTree(fpnode* bottom) { // bottom est un des noeuds contenant l'élément
  std::vector res;                                                                       // dont on veut créer l'arbre conditionnel 
  while (bottom->parent != root) {
    res.push_back(bottom->parent->label);
    bottom = bottom->parent;
  }
  return res;
}

Voici maintenant la fonction qui produit l'ensemble des s�quences ascendantes. Une fr�quence est attribu�e � chacune des s�quences: elle correspond � la fr�quence du noeud dont on part.

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
template <class Item>
std::vector, int>> fptree::getConditionalPatterns(const Item& i) {
  std::vector, int>> res; // un vector de paires 
  auto bnode = headerTable[i].cousins; // à partir de la table des éléments
  for (;;) {                                           // on parcourt tous les noeuds cousins
    if (!bnode) break;
    res.push_back(std::make_pair(ascendTree(bnode), bnode->count));
    bnode = bnode->cousins; 
  }
  return res;
}

Redondance, redondance...
La construction de l'arbre conditionnel est d�sormais semblable � la construction de l'arbre initial, � la nuance pr�s que les s�quences sont annot�es d'une fr�quence:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
template <class Item>
bool fptree::buildTree(const std::vector, int>>& input) {
  for (auto& kv : input)
    scanSequenceForFrequency(kv.first, kv.second);
  for (auto kv : input)
    scanSequenceIntoTree(kv.first, kv.second);
  return root->children;
}

Malgr� les similitudes, on ne peut pas �chapper � l'�criture d'une surcharge, � cause de mauvais choix initiaux; comparez la fonction au-dessus et la fonction en-dessous, utilis�e pour cr�er l'arbre initial:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
template <class Item>
bool fptree::buildTree(const std::vector>& input) {
  for (auto& vi : input)
    scanSequenceForFrequency(vi);
  for (auto vi : input) 
    scanSequenceIntoTree(vi);
  return root->children; // si la racine a un enfant, l'arbre n'est pas vide
}

On dirait du copier-coller, hein? Le p�re de tous les anti-patterns? h� bien oui.

Des arbres conditionnels aux associations fr�quentes
Vous passerez des arbres conditionnels aux associations fr�quentes en construisant des pr�fixes. Lors du premier passage dans l'arbre, le pr�fixe est vide. Au deuxi�me passage, le pr�fixe est constitu� de l'�l�ment fr�quent dont vous avez construit l'arbre conditionnel. Au troisi�me passage, on ajoute l'�l�ment fr�quent de l'arbre conditionnel dont vous construisez l'arbre conditionnel, et ainsi de suite, jusqu'� ce que l'arbre conditionnel soit vide. Le pr�fixe constitue une association fr�quente: en effet, l'�l�ment n du pr�fixe est fr�quent dans l'arbre conditionnel de l'�l�ment n-1 du pr�fixe.

Pour explorer correctement l'ensemble de l'arbre, vous commencez l'extraction par l'�l�ment le moins fr�quent, dont les noeuds se trouvent le plus loin de la racine. Voici la fonction mineTree, qui extraie les associations fr�quentes, et que vous pouvez d�sormais comprendre sans encombre:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
template <class Item>
void fptree::mineTree(std::vector, int>>& patterns, const std::vector& prefix) {
 
  // retrieve items with mininum support 
  deleteInfrequentItems(); // retire de la headerTable (table des éléments)  les éléments qui ne sont pas assez fréquents
  std::vector keys;
  for (auto& kv : headerTable) keys.push_back(kv.first); 
 
  // sort keys in increasing order of frequency
  std::sort(std::begin(keys), std::end(keys), [&](const Item& a, const Item& b) {
      return headerTable[a].count < headerTable[b].count; 
    });
 
  // get conditional patterns and create their fptrees
  for (auto& k : keys) {
    std::vector nprefix = prefix;
    nprefix.push_back(k); // augment prefix with new key
    patterns.push_back(std::make_pair(nprefix, headerTable[k].count));
 
    fptree cfpt(minsup); // recursively build new fptree
    bool items_left = cfpt.buildTree(getConditionalPatterns(k));
    if (items_left)
      cfpt.mineTree(patterns, nprefix); // recursively mine the new fptree
  }
}

Ouf!
Nous en avons termin� avec l'impl�mentation na�ve. Maintenant nous allons pouvoir commencer le vrai travail, raffiner l'impl�mentation jusqu'� ce qu'elle soit agr�able � utiliser et aussi performante et extensible que possible! Nous nous y attellerons dans le prochain billet!

A vous de jouer

Quels sont, � votre avis, les fonctions indispensables qui constitueront l'interface minimale de notre structure de donn�es?
Faut-il r�duire une interface au minimum de fonctions requises pour exploiter la structure de donn�es?

Pour exp�rimenter, voici in extenso les fichiers source:
- fptree.h

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
#ifndef __FP_FPTREE_H
#define __FP_TREE_H
 
#include "fpnode.hpp"
#include 
#include 
#include 
 
template <class Item>
class fptree {
public:
  // les données de l'arbre
  std::unordered_map> headerTable;
  fpnode* root;
  int minsup; // la fréquence minimale à respecter
 
  //constructeur / destructeur
  fptree(int sup) : root(new fpnode()), minsup(sup) {}
  ~fptree() { deleteNode(root);  }
 
  // les fonctions pour construire la fp-tree
  bool buildTree(const std::vector>& input);
  bool buildTree(const std::vector, int>>& input);
  void scanSequenceForFrequency(const std::vector& input, int freq = 1);
  void deleteInfrequentItems();
  void scanSequenceIntoTree(std::vector& input, int freq = 1);
 
  //les fonctions pour chercher les associations fréquentes
  void mineTree(std::vector, int>>& patterns, const std::vector& prefix);
  std::vector ascendTree(fpnode* bottom);
  std::vector, int>> getConditionalPatterns(const Item& i);
 
  void show();   
};
 
template <class Item>
void fptree::scanSequenceForFrequency(const std::vector& input, int freq) {
  for (auto& item : input) {
    auto kv = headerTable.find(item);
    if (kv != headerTable.end()) {
      kv->second.count += freq;
    }
    else headerTable[item].count = freq;
  }
}
 
template <class Item>
void fptree::deleteInfrequentItems() {
  std::vector to_erase;
  for (auto& kv : headerTable) {
    if (kv.second.count < minsup) to_erase.push_back(kv.first);
  }
  for (auto& i : to_erase) {
    headerTable.erase(i);
  }
}
 
template <class Item>
void fptree::scanSequenceIntoTree(std::vector& input, int freq) {
  input.erase(std::remove_if(std::begin(input), 
			     std::end(input), 
			     [&](const Item& i) { return headerTable[i].count < minsup; }),
	      std::end(input)); // delete elements under minimal freq support
  std::sort(std::begin(input), 
	    std::end(input), 
	    [&](const Item& a, const Item& b) {
	      return headerTable[a].count == headerTable[b].count ? 
		std::less()(a, b) : 
		headerTable[a].count > headerTable[b].count;
	    }); // most frequent elements first
  fpnode* n = root;
  for (auto& i : input) {
    auto pair = n->addChild(i, freq);
    n = pair.first;
    if (pair.second) {
      n->cousins = headerTable[i].cousins;
      headerTable[i].cousins = n;
    }
  }
}
 
template <class Item>
std::vector fptree::ascendTree(fpnode* bottom) {
  std::vector res;
  while (bottom->parent != root) {
    res.push_back(bottom->parent->label);
    bottom = bottom->parent;
  }
  return res;
}
 
template <class Item>
std::vector, int>> fptree::getConditionalPatterns(const Item& i) {
  std::vector, int>> res;
  auto bnode = headerTable[i].cousins;
  for (;;) {
    if (!bnode) break;
    res.push_back(std::make_pair(ascendTree(bnode), bnode->count));
    bnode = bnode->cousins;
  }
  return res;
}
 
template <class Item>
bool fptree::buildTree(const std::vector, int>>& input) {
  for (auto& kv : input)
    scanSequenceForFrequency(kv.first, kv.second);
  for (auto kv : input)
    scanSequenceIntoTree(kv.first, kv.second);
  return root->children;
}
 
template <class Item>
bool fptree::buildTree(const std::vector>& input) {
  for (auto& vi : input)
    scanSequenceForFrequency(vi);
  for (auto vi : input) 
    scanSequenceIntoTree(vi);
  return root->children;
}
 
template <class Item>
void fptree::mineTree(std::vector, int>>& patterns, const std::vector& prefix) {
 
  // retrieve items with mininum support 
  deleteInfrequentItems();
  std::vector keys;
  for (auto& kv : headerTable) keys.push_back(kv.first); 
 
  // sort in increasing order of frequency
  std::sort(std::begin(keys), std::end(keys), [&](const Item& a, const Item& b) {
      return headerTable[a].count < headerTable[b].count; 
    });
 
  // get conditional patterns and create their fptrees
  for (auto& k : keys) {
    std::vector nprefix = prefix;
    nprefix.push_back(k); // augment prefix with new key
    patterns.push_back(std::make_pair(nprefix, headerTable[k].count));
 
    fptree cfpt(minsup); // recursively build new fptree
    bool items_left = cfpt.buildTree(getConditionalPatterns(k));
    if (items_left)
      cfpt.mineTree(patterns, nprefix);
  }
}
 
template <class Item>
void fptree::show() {
  root->show(0);
}
 
#endif

-fpnode.h

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#ifndef __FP_NODE_H
#define __FP_NODE_H
 
#include 
 
template <class Item>
struct fpnode {
  Item label;
  int count;
  fpnode *parent, *brothers, *children, *cousins;
 
fpnode() : label{}, count(0), parent(nullptr), brothers(nullptr), children(nullptr), cousins(nullptr) {};
fpnode(fpnode* father, const Item& name, int freq, fpnode* bro) : label(name), count(freq), parent(father), brothers(bro), children(nullptr), cousins(nullptr) {}
 
  fpnode* hasChild(const Item& name) { // return the name named child if found, nullptr otherwise
    fpnode* n = children;
    while (n) {
      if (n->label == name) break;
      n = n->brothers;
    }
    return n;
  }
 
  std::pairbool> addChild(const Item& name, int freq=0) {
    fpnode* n = hasChild(name);
    if (!n) {
      children = new fpnode(this, name, freq, children);
      return std::make_pair(children, true);
    }
    else n->count += freq;
    return std::make_pair(n, false);
  }
 
  void show(int offset) {
    std::cout << std::string(offset, ' ') << label << " - " << count << std::endl;
    for (fpnode* n = children; n; n=n->brothers) {
      n->show(offset+2);
    }
  }
 
};
 
template <class Item>
void deleteNode(fpnode* n) {
  if (n->children) {
    for (fpnode* ch = n->children; ch; ch = ch->brothers) {
      deleteNode(ch);
    }
  }
  delete n;
}
 
#endif

Images attach�es

D�tection des associations fr�quentes en C++ - premi�re partie

stendhal666 — Sat, 26 Dec 2015 16:15:45 GMT

Comme je l'indiquais dans le billet pr�c�dent, je propose maintenant une impl�mentation na�ve, reprise presqu'exactement d'une impl�mentation en Python, de l'algorithme de d�tection des associations fr�quentes centr� autour d'une structure de donn�e appel�e frequent pattern tree, ou arbre des associations fr�quentes. Il peut �tre utile de relire la pr�sentation de l'algorithme

Une impl�mentation na�ve
Une impl�mentation en Python se ressent souvent de l'utilisation de ce langage pour cr�er des prototypes: plut�t que de chercher d'embl�e � �crire une librairie bien finie qu'on pourra utiliser sans risque dans des programmes plus vastes, on cherche � mettre au point rapidement quelques briques logicielles � confronter � des donn�es de test. Ni la performance, ni la s�ret� ne sont recherch�es prioritairement mais plut�t la simplicit� et la r�utilisation de la vaste librairie standard de ce langage "piles incluses".

Pour g�n�rer quelques donn�es d'associations fr�quentes, on fera donc une liste de listes; en C++ il faut ajouter un type mais gr�ce aux nouvelles std::initializer_list de C++11, on a des possibilit�s semblables:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
  std::vector> bseq = // nos données de test
    {
      {"r", "z", "h", "j", "p" },
      {"z", "y", "x", "w", "v", "u", "t", "s" },
      {"z"},
      {"r", "x", "n", "o", "s"},
      {"y", "r", "x", "z", "q", "t", "p"},
      {"y", "z", "x", "e", "q", "s", "t", "m"}
    };

Une interface na�ve
L'interface de notre classe FP-Tree, na�vement, est con�ue pour �pouser la forme des donn�es de test; pour pousser la ressemblance avec Python, l'encapsulation des donn�es est laiss�e de c�t�...

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
template <class Item>
class fptree {
public:
  // les données de l'arbre
  std::unordered_map> headerTable;
  fpnode* root; // la classe fpnode sera définie plus loin
  int minsup; // la fréquence minimale à respecter
 
  //constructeur / destructeur
  fptree(int sup) : root(new fpnode()), minsup(sup) {}
  ~fptree() { deleteNode(root);  }
 
  // les fonctions pour construire la fp-tree
  bool buildTree(const std::vector>& input);
  bool buildTree(const std::vector, int>>& input);
  void scanSequenceForFrequency(const std::vector& input, int freq = 1);
  void deleteInfrequentItems();
  void scanSequenceIntoTree(std::vector& input, int freq = 1);
 
  //les fonctions pour chercher les associations fréquentes
  void mineTree(std::vector, int>>& patterns, const std::vector& prefix);
  std::vector ascendTree(fpnode* bottom);
  std::vector, int>> getConditionalPatterns(const Item& i);
 
  void show();   
};

Sans analyser trop pr�cis�ment cette interfacte "pythonesque", plusieurs choses sautent aux yeux:
- pas d'encapsulation des donn�es, impossible de changer quoique ce soit une fois la librairie offerte au vaste monde...
- une interface beaucoup trop grosse. Impossible de s'y rep�rer ais�ment, de la comprendre facilement
- beaucoup de structures de donn�es fig�es; m�me s'il est devenu beaucoup plus facile en C++11 d'it�rer sur un conteneur et donc de construire un conteneur d'un autre type avec, on sent que l'interface sera contraignante d�s que le sc�nario retenu pour prototyper la librairie ne sera pas respect�

Pour l'instant, tout va bien
Malgr� tous ces d�fauts, pour chercher les associations fr�quentes dans notre sc�nario id�al, il suffit de faire:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
fptree fpt(3); // fréquent = au moins trois occurrences
fpt.buildTree(bseq); // bseq = les données définies à l'instant
std::vector, int>> fpatterns; // la structure pour accueillir les résultats
fpt.mineTree(fpatterns, std::vector()); // on lance l'analyse des associations fréquentes

Le r�sultat est le suivant:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
// toutes les associations apparaissant plus de trois fois, avec leur nombre d'occurrences
s : 3 // pour être précis, c'est l'association d'un élément et de l'élément nul
s x : 3
t : 3
t z : 3
t z x : 3
t x : 3
y : 3
y z : 3
y z t : 3
y z x : 3
y z x t : 3
y x : 3
y x t : 3
y t : 3
r : 3
x : 4
x z : 3
z : 5

La fonction show permet de visualiser l'arbre, m�me si d'�vidence il faudrait faire mieux:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
 - 0 // la racine
  x - 1 // plus la ligne est indentée, plus l'élément est loin de la racine
    r - 1
      s - 1
  z - 5
    x - 3
      r - 1
        t - 1
          y - 1
      s - 2
        t - 2
          y - 2
    r - 1

Un arbre familial
Pour rentrer un peu plus avant dans l'impl�mentation, il faut pr�senter les noeuds de l'arbre. Comme l'arbre s'appelle fptree, les noeuds s'appellent fpnode:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
template <class Item>
struct fpnode {
  Item label;
  int count; // la fréquence
  fpnode *parent, *brothers, *children, *cousins; // toute la famille
(...)
};

Chaque noeud a:
- un parent;
- des enfants (children): en fait le pointeur pointe sur l'a�n� des enfants; pour retrouver les autres enfants, il faut suivre le pointeur qui part de l'a�n� vers ses fr�res (brothers);
- des fr�res, donc;
- des cousins: ce sont les autres �l�ments de l'arbre qui ont le m�me label.

Ajouter une s�quence d'�l�ments � l'arbre
Comme je l'expliquais dans le billet pr�c�dent, il y a deux grandes �tapes dans la construction d'une FP-Tree. La premi�re consiste � parcourir tous les �l�ments de toutes les s�quences pour d�terminer leur fr�quence. Il n'y a pas de difficult� particuli�re:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
template <class Item>
void fptree::scanSequenceForFrequency(const std::vector& input, int freq) {
  for (auto& item : input) {
    auto kv = headerTable.find(item);
    if (kv != headerTable.end()) { // si l'élément est déjà connu
      kv->second.count += freq; // on augmente sa fréquence
    }
    else headerTable[item].count = freq; // sinon on l'ajoute à la table
  }
}

Lorsque la fr�quence de tous les �l�ments est connue, on peut ajouter des s�quences � l'arbre proprement dit, � partir de la racine. C'est le r�le de la fonction:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
template <class Item>
void fptree::scanSequenceIntoTree(std::vector& input, int freq)

Ne seront ajout�s que les �l�ments fr�quents; pour que l'arbre soit le plus compress� possible, il faut ajouter les �l�ments de la s�quence en commen�ant par les plus fr�quents:

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
 
  input.erase(std::remove_if(std::begin(input), 
			     std::end(input), 
			     [&](const Item& i) { return headerTable[i].count < minsup; }),
	      std::end(input)); // enlever éléments non fréquents
  std::sort(std::begin(input), 
	    std::end(input), 
	    [&](const Item& a, const Item& b) {
	      return headerTable[a].count == headerTable[b].count ? 
		std::less()(a, b) : 
		headerTable[a].count > headerTable[b].count;
	    }); // les plus fréquents d'abord + clé secondaire

NB: j'ai utilis� de fonctions lambda, qui permettent de tirer parti des algorithmes de la biblioth�que standard de fa�on agr�able. Ce sont des petites fonctions, famili�res dans un langage comme Python, d�finies localement et que l'on passe facilement en argument � d'autres fonctions.

On peut alors ajouter la s�quence � l'arbre. L'ajout se fait � la racine, �l�ment par �l�ment, de fa�on r�cursive: si la racine a un enfant nomm� comme le premier �l�ment, on en augmente la fr�quence; sinon, on cr�e un nouvel enfant pour la racine. Et on recommence l'op�ration sur le noeud obtenu.

D�s qu'on cr�e un nouveau noeud il faut l'indexer dans la headerTable: cette liste des cousins permettra de retrouver tous les chemins partant d'un des �l�ments vers la racine lorsque nous rechercherons les associations fr�quentes.

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
  fpnode* n = root;
  for (auto& i : input) {
    auto pair = n->addChild(i, freq);
    n = pair.first;
    if (pair.second) { // pair second == true <=> un nouveau noeud a été créé
      n->cousins = headerTable[i].cousins; // on met à jour la table des éléments
      headerTable[i].cousins = n;

NB: deux "features" nouvelles de C++11 sont utilis�es ici: auto pour d�duire le type d'une variable � initialiser et la construction (for element : conteneur) { ... } qui �quivaut �:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
for (std::conteneur::iterator it = std::begin(conteneur); it != std::end(conteneur); ++it) {
  conteneur::value_type element = *it; 
  ... }

Pensez � utiliser auto& si vous voulez �viter de copier les �l�ment du conteneur.

Une fois l'arbre construit, il devient possible de chercher les associations fr�quentes sans plus retourner � la base de donn�es. Nous verrons cela dans la prochain billet mais en attendant, joyeux No�l! :lahola:

A suivre...

D�tection des associations fr�quentes en C++ - Introduction

stendhal666 — Wed, 23 Dec 2015 13:20:12 GMT

Pour ceux qui ont suivi ce blog dans une vie ant�rieure, ce billet n'a aucun rapport avec les pr�c�dents. J'ai �chou� � susciter le d�bat autour de la programmation fonctionnelle, dont acte. La s�rie de billets que je pr�pare portera sur l'�laboration d'une petite biblioth�que d'apprentissage machine en C++ moderne en essayant de faire ressortir la singularit� de ce langage. Il serait peut-�tre plus avis� de cr�er un autre blog mais la r�gle de developpez.net semble �tre: un utilisateur, un blog, et je m'y plie bien volontiers. Cela dit, commen�ons.

Les associations fr�quentes, ou frequent patterns
Le premier algorithme que nous d�velopperons devra permettre, dans un ensemble de s�quences, de d�tecter les associations d'�l�ments les plus fr�quentes. Imaginez que vous �tes embauch�s par votre libraire: il veut pouvoir sugg�rer d'autres lectures � ses clients lorsqu'ils passent � la caisse et vous demande donc le moyen de savoir quels sont les livres fr�quemment achet�s ensemble... Et vous voil� � chercher des associations! Voici deux autres exemples de l'utilisation qu'on peut en faire:

- proposer une saisie dans un moteur de recherche: lorsque vous tapez votre recherche, le moteur propose souvent de la compl�ter; ses propositions sont tir�es des associations les plus fr�quentes dans les recherches pr�c�dentes. Donc, si vous voulez vous faire une id�e de ce que pense le sexe oppos� � votre sujet, tapez: "Pourquoi les hommes" ou "Pourquoi les femmes" et le moteur vous proposera des recherches avis�es, comme: "Pourquoi les hommes adorent les chieuses", "Pourquoi les hommes mentent", etc. Ce n'est pas que le moteur a un avis sur la question, c'est juste que c'est une question fr�quemment pos�e.

- fixer la disposition des rayons et les prix dans un magasin: en prenant la liste des achats de vos clients, et en d�tectant les associations fr�quentes, vous pouvez d�cider de rapprocher -ou d'�loigner- des produits, voire d'en fixer les prix. L'exemple le plus c�l�bre est celui des bi�res et des couches: un magasin am�ricain avait remarqu�, par cette m�thode, que ses clients achetaient souvent ensemble bi�res et couches; ils en avaient d�duit que les maris envoy�s faire les courses pour les enfants se d�dommageaient de leur peine en prenant quelques bi�res. Moralit�, les bi�res -plein tarif- ont �t� plac�es � c�t� des couches, pour encourager � la consommation.

On pourrait r�fl�chir � bien d'autres fa�ons d'utiliser les associations fr�quentes: faire le menu d'un restaurant, am�liorer l'interface d'un logiciel, etc.

Qu'est-ce qu'un association fr�quente?
Essayons de donner une d�finition plus rigoureuse des associations fr�quentes: soit un ensemble d'�l�ments que nous appellerons E. Soit des s�quences, ou transactions, qui sont des sous-ensembles de E. Une association fr�quente est un sous-ensemble de E qui est �galement un sous-ensemble d'un nombre d�termin� (fr�quent) de s�quences.
Il y a deux fa�ons de d�finir le caract�re fr�quent d'une association: on peut fixer un seuil d'apparition, 10 apparitions, par exemple, ou bien un pourcentage: si l'�l�ment appara�t dans au moins 5% des s�quences analys�es, on consid�rera qu'il est fr�quent. N�anmoins, une fois que l'on conna�t le nombre de s�quences � analyser, la deuxi�me d�finition est r�ductible � la premi�re.

Quels sont les algorithmes utilis�s?
La force brute
ne convient que pour les petites bases de donn�es. On g�n�re d'abord l'ensemble des �l�ments apparaissant dans la base de donn�es, puis tous ses sous-ensembles, et on v�rifie la fr�quence de chacun des sous-ensembles dans la base de donn�es. Mettons que vous ayez 99 articles dans votre magasin, vous aurez 2¹⁰⁰ sous-ensembles � v�rifier. C'est long. Si vous �tes un moteur de recherche, et m�me si vous avez la puissance de calcul de Google, imaginez le nombre de sous-ensembles et reconnaissez que vous �tes foutus.

L'algorithme a priori
L'algorithme appel� a priori repose sur une propri�t� �vidente des associations fr�quentes: si un �l�ment, ou un sous-ensemble, n'est pas fr�quent, aucun des ensembles qui le contient ne le sera. Si le sous-ensemble { "femme", "simple" } n'est pas fr�quent, alors { "femme", "simple", "caract�re", "�gal" } ne le sera pas non plus.

Que peut-on en tirer d'un point de vue algorithmique (je vous laisse en tirer les conclusions que vous voulez pour votre vie sentimentale)? Si un sous-ensemble n'est pas fr�quent, il n'est pas n�cessaire de v�rifier les sous-ensembles qui le contiennent; c'est ce que fait l'algorithme a priori: on commence par g�n�rer tous les sous-ensembles d'un seul �l�ment - on raye les sous-ensembles qui n'atteignent pas le seuil requis - on combine les sous-ensembles restant pour former des sous-ensembles de deux �l�ments - on raye ceux qui n'ont pas la fr�quence requise - on combine pour obtenir des ensembles � trois �l�ments, et ainsi de suite, jusqu'� �puisement.

Quoiqu'il r�duise le nombre de passage dans la base de donn�es, il reste n�cessaire de scanner la base de donn�es pour chaque combinaison, ce qui peut �tre un gros d�savantage d�s que la connexion/la lecture est lente.

L'arbre des associations fr�quentes, ou frequent pattern tree
C'est l'algorithme que nous impl�menterons ensemble et longuement. C'est un algorithme nettement plus compliqu� mais nettement plus efficace. Vous pouvez jeter un oeil � l'article original ici (c'est un pdf dans une archive), ou taper "frequent pattern tree" dans votre moteur de recherche favori, vous le trouverez facilement. Il promet d'�tre, pour la plupart des donn�es � analyser, plus rapide de plusieurs ordres de grandeur. Son premier avantage est de ne demander que deux passages dans la base de donn�es: le premier pour d�terminer les �l�ments fr�quents, le deuxi�me pour construire l'arbre lui-m�me. Toutes les op�rations suivantes sont effectu�es sur l'arbre, qui est une version r�duite et pratique de la base de donn�es

L'AAF est compos� de deux �lements principaux:
- un arbre qui contient les s�quences de la base de donn�es tri�es et condens�es
- une table qui permet de retrouver dans l'arbre tous les noeuds qui renvoient au m�me �l�ment.

En voici un exemple (avec une fr�quence minimum de 1, ce qui n'est pas tr�s repr�sentatif, certes), illustrant mes capacit�s en dessin. Il est extrait de la base de donn�es suivante:

s1: { eau }
s2: { eau, bi�re, couches }
s3: { eau, bi�re, chips}
s4: { eau }
s5: { bi�re, vodka }
s6: { eau, bi�re, couches }

Les grandes �tapes de la construction de l'AAF
1. scannez la base de donn�es pour obtenir, pour chaque �l�ment pr�sent, sa fr�quence et construisez partiellement la table avec.
2. scannez � nouveau la base de donn�es, et pour chaque s�quence:
2.1: retirer les �l�ments qui ne sont pas assez fr�quents
2.2: triez-les dans l'ordre d�croissant de fr�quence
2.3: ajoutez-les � l'arbre: ne cr�ez un nouveau noeud que si la s�quence ajout�e ne se confond pas avec une s�quence pr�c�dente; sinon augmentez simplement la fr�quence du noeud: dans l'exemple que j'ai donn�, { eau } cr�e un nouveau noeud car l'arbre �tait vide; { eau, bi�re, couches } cr�e deux noeuds puisque son premier �l�ment �tait d�j� � la bonne place dans l'arbre; { eau, bi�re, chips } cr�e un seul nouveau noeud puisque les deux premiers �l�ments �taient � la bonne place, etc.
Voil�, votre arbre est pr�t.

Trouver les associations fr�quentes
C'est � la fois plus simple � faire et plus compliqu� � concevoir; la d�tection tire partie des propri�t�s de l'AAF.
1. On reprend les �l�ments fr�quents dans la table et on les trie dans l'ordre croissant de fr�quence
2. Pour chacun de ces �l�ments:
2.1: on ajoute l'�l�ment, avec un pr�fixe initialement vide, � la liste des associations fr�quentes // le sens du pr�fixe se comprend en 2.3
2.2 on prend l'ensemble des chemins qui partent des noeuds contenant cet �l�ment et vont vers la racine de l'arbre
2.3 on cr�e une nouvelle AAF avec ces chemins et on recommence en ajoutant l'�l�ment au pr�fixe utilis� en 2.1
Voil�, vos associations sont trouv�es

Le programme pour la suite
Mon projet n'est pas seulement d'impl�menter l'algorithme en C++. Je proposerai dans le prochain billet une interpr�tation na�ve, qui est la transcription en C++ d'une impl�mentation en Python que j'ai trouv� dans l'excellent Machine learning in Action de Peter Harrington. En partant de ce prototype grossier, nous raffinerons ensemble -j'esp�re avoir en commentaire des propositions- la conception et l'impl�mentation de l'algorithme dans un esprit C++.

Analyse syntaxique monadique

stendhal666 — Thu, 07 May 2015 15:40:07 GMT

Continuons � explorer les flots de la th�orie des cat�gories. Le pr�c�dent billet reposait sur un exemple tr�s simple et tr�s artificiel. L�ambition de celui-l� est de proposer des techniques utilisables au jour le jour par un d�veloppeur et fond�es sur l�utilisation des cat�gories.

Analyses
L�analyse de texte est une de ces t�ches de tous les jours. Par texte, j�entends un flux de donn�es (caract�res, octets, peu importe) qui suit des r�gles formalis�es par un langage. Certains de ces langages sont peu ambitieux, comme le format csv ; et d�autres le sont extr�mement, comme le C++. Par analyse, j�entends la transformation de ce flux brut en un r�sultat structur� et exploitable.

Sous forme d�explication d�une � perle fonctionnelle � dont l�article original est disponible ici, j�esp�re convaincre que les cat�gories peuvent offrir des outils de tous les jours, commodes et puissants � la fois.

Description na�ve et fonctionnelle
Essayons de d�crire la t�che � accomplir : nous avons un flux, nous en extrayons des donn�es. Cela fait d�j� deux types, mettons s pour le flux et a pour la donn�e � extraire. Et bien s�r un troisi�me type, s -> a, qui est la fonction d�extraction. Cette premi�re approche pourrait �tre retenue dans un langage imp�ratif :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
 
typedef int Data ;
typedef std::string Stream ;
Data parseInt(Stream& s) { … } // retourne le premier int décelable et retire du flux les caractères qui le composent
N�anmoins elle repose sur la possibilit� de modifier le flux d�entr�e pour analyser le prochain entier. Outre que c�est impossible dans un langage fonctionnel pur comme Haskell, ce n�est m�me pas d�sirable, puisqu�on pourrait souhaiter appliquer deux analyseurs diff�rents au m�me � moment � du flux et d�cider en fonction du r�sultat, par exemple.

Transformons un peu notre troisi�me type pour r�gler le probl�me: un analyseur fonctionnel prend un flux en entr�e et retourne un couple (donn�e, flux); ainsi le flux d�entr�e est conserv�e � l�identique et le flux � consomm� � est int�gr� au type de retour. Voici donc le type transform�: s -> (a, s).

Comme un analyseur peut retourner z�ro ou plusieurs r�ponses (dans le cas d�une grammaire ambigu�, par exemple) il faut transformer encore un peu notre type; nous parvenons � : s -> [(a, s)]. Aucune r�ponse, l�analyseur renvoie la liste vide ; plusieurs, il renvoie la liste des candidats.

Notre monade
Nous avons donc d�fini le type de notre analyseur. En choisissant une cha�ne de caract�re pour repr�senter le flux, par souci de simplification, nous avons :

newtype Parser a = Parser (String -> [(a, String)])

N.B : newtype est une directive qui permet de recouvrir un type, en lui donnant un autre nom. Contrairement � un alias (ex: typedef), elle cr�e bien un nouveau type, sans conversion implicite possible.

Comme nous ne pouvons plus lancer directement notre analyseur, nous cr�ons une fonction d�appoint qui lance l�analyseur :
parse :: (Parser a) -> (String -> [(a, String)])
parse (Parser p) = p

il est possible d�s lors de lancer l�analyseur de la fa�on suivante :
> parse parseur flux

Prenons l�analyseur le plus simple possible, qui extrait un caract�re d�une cha�ne :
item :: Parser Char
item = Parser (\cs -> case cs of

(c:nc) -> [(c, nc)]
_ -> [])
N.B : case x of

Cas1 -> rep1
Cas2 -> rep2
est l��quivalent d�un switch qui permet le pattern-matching

> parse item "abc"
[(a, "bc")]

Rencontre du quatri�me type
Il nous reste un dernier type � explorer, peut-�tre le plus important. Dans notre exemple na�f, la fonction parse contenait les diff�rentes informations n�cessaires � la cr�ation de l�analyseur: la liste des caract�res acceptables pour fournir un entier, le nombre de caract�res � lire ou le point d�arr�t � attendre, les mesures � prendre en cas d��chec, etc. Pour peu qu�on extraie cette logique des fonctions cod�es � en dur �, on pourra cr�er � loisir, par modification, enrichissement, composition, autant d�analyseurs qu�on le souhaite � partir de quelques primitives.

Le quatri�me type est donc celui d�un � constructeur � d�analyseurs, qui associe � un param�tre quelconque (une liste, un caract�re, une fonction, etc.) un analyseur, soit a -> Parser b.

Ce quatri�me type est utilis� pour d�finir les m�thodes monadiques, composition et identit�, du type Parser.

Identit� et composition
La fonction identit� a justement pour signature : a -> Parser a. L�id�e derri�re l�identit� est d�injecter a dans la monade mais en ajoutant le minimum de contexte monadique possible. Elle est donc simplement d�finie par :

return a = Parser (\cs -> [(a, cs)])

C�est-�-dire qu�elle renvoie un parseur qui laisse le flux inchang� et renvoie la donn�e en argument.

La composition demande plus de r�flexion :

(>>=) :: Parser a -> (a -> Parser b) -> Parser b
p >>= f = Parser (\cs -> concat [parse (f a) cs' | (a, cs') <- parse p cs])

Cette d�finition tr�s opaque demande � �tre explicit�e :
- l�argument de concat est une list comprehension :
- 1) pour chacun des r�sultats (a, cs�) qui proviennent de l�analyse de cs par p,
- 2) on applique f :: a -> Parser b � a et
- 3) on analyse cs� avec le(s) Parser(s) ainsi obtenus.
- Cette list comprehension produit donc une liste de listes de couples (a, s) ; concat permet d�en faire une seule liste (concat :: [[a]] -> [a])
Cette d�finition permet ainsi de composer deux analyseurs qui peuvent renvoyer une pluralit� de r�sultats.

Enrichir la monade
Lorsqu�on regarde la d�finition de la composition, on s�aper�oit que, si l�analyseur p �choue, c�est-�-dire renvoie la liste vide, la fonction f ne sera jamais appel�e. Un analyseur qui retourne une liste vide a donc des propri�t�s particuli�res, semblables � celle de 0 pour la multiplication :

mzero = Parser (cs -> [])
mzero >>= f = mzero

mzero est l��l�ment absorbant de la composition des analyseurs, de m�me que 0 est l��l�ment absorbant de la multiplication des nombres r�els.

A ce stade, nous pouvons donner un premier exemple d�analyseur compos�. Nous avons mis au point une primitive item qui renvoie le premier caract�re d�un flux. Nous voudrions maintenant cr�er un analyseur qui renvoie le premier caract�re s�il satisfait une certaine condition :

sat :: (Char -> Bool) -> Parser Char
sat f = item >>= \c -> if f c then return c else mzero

La do-notation
Une notation plus lisble, un sucre syntaxique est disponible dans Haskell pour manipuler les monades

Vanilla do-notation

sat = sat = do

item >>= \c -> c <- item

if f c then� if f c then�

Si on veut l�utiliser sans sauter de lignes, on peut placer les instructions entre accolades et les s�parer par des points-virgules. Nous utiliserons la do-notation � l�avenir, qui est souvent plus claire. Un exercice peut-�tre de les reconvertir en notation sal�e.

Ainsi, en do-notation :

sat = do { c <- item ; if f c then return c else mzero }

> parse (sat isDigit) "123"
[('1', "23")]

> parse (sat isDigit) "abc"
[]

Pour extraire un caract�re en particulier, nous pouvons cr�er :
char :: Char -> Parser Char
char c = sat (c==)

Des analyseurs r�cursifs
Nous sommes �galement en mesure de cr�er des analyseurs r�cursifs. Si l�on veut extraire une cha�ne du flux, nous pouvons par exemple �crire :
string :: String -> Parser String
string "" = return ""
string (c:cs) = do { x <- char c; xs <- string cs; return (x : xs) }

Cette r�cursion fonctionne de la m�me fa�on que la r�cursion fonctionnelle habituelle. Il y a un cas d�arr�t (string "") et un cas n+1. Il est �clairant de noter que si, dans le cas n+1, la fonction 'char' �choue, elle renverra l��l�ment absorbant mzero et que donc la fonction 'string' sera �gale � mzero :

> parse (string "abc") "abcdef"
[("abc", "def")]

> parse (string "abc") "defghi"
[]

Enrichir encore la monade
0 est l��l�ment absorbant de la multiplication, mais il est �galement l��l�ment neutre de l�addition : x + 0 = x
En d�finissant une fonction d�addition pour nos analyseurs, nous pouvons �galement donner ce r�le � mzero :

mplus :: Parser a -> Parser a -> Parser a
mplus p q = Parser (\cs -> (parse p cs) ++ (parse q cs))

N.B. (++) concat�ne deux listes

mplus concat�ne les listes de r�sultats obtenus en appliquant p et q � cs. Or [] ++ [1,2,3] = [1,2,3] et [1,2,3] ++ [] = [1,2,3]. mzero, comme 0, est ainsi, selon la relation choisie, soit l��l�ment absorbant, soit l��l�ment neutre (au passage, nous venons de d�finir un mono�de, c�est-�-dire un ensemble pourvu d�une op�ration associative qui admet un �l�ment neutre).

Lorsque mzero et mplus sont d�finis pour un type, il peut �tre d�fini comme une instance de la cat�gorie MonadPlus.

Comme nous choisirons des exemples d�analyseurs simples et d�terministes, mplus peut �tre restreint par un op�rateur (+++) qui ne retient que le premier choix possible parmi ceux renvoy�s par mplus :

(+++) :: Parser a -> Parser a -> Parser a
p +++ q = Parser (cs -> case p `mplus` q of

[] -> []
(r:_) -> [r])

De l�int�r�t d��tre un mono�de.
Gr�ce � ses fonctionnalit�s suppl�mentaires, notre type Parser peut d�sormais g�rer l��chec. Tandis que mzero permet de le repr�senter, mplus et son d�riv� (+++) permettent de le surmonter.

On peut ainsi d�finir deux constructeurs d�analyseurs many et many1, qui prennent en argument un analyseur plus primitif et qui le r�p�tent respectivement un nombre ind�fini de fois et au moins une fois :

many :: Parser a -> Parser [a]
many p = many1 p +++ (return [])

Attention, return [] est diff�rent de mzero : return [] = Parser (cs -> [([], cs)] tandis que mzero = Parser (cs -> []).

Ainsi, si many1 �choue, many retourne un r�sultat positif de 0 occurrences. En effet, mzero `mplus` (return []) = mzero +++ (return []) = return [] puisque mzero est l��l�ment neutre.

many1 :: Parser a -> Parser [a]
many1 p = do {t <- p; ts <- many p; return (t:ts) }

> parse (many1 (char 'b')) "bbc"
[(['b', 'b'], "c")]
> parse (many (char 'b')) "abbc"
[([], "abbc")]
> parse (many1 (char 'b')) "abbc"
[]

Un dernier pas avant Pascal�
Sur le m�me mod�le, nous d�finissons encore deux constructeurs d�analyseurs qui nous permettront de composer un analyseur d�expressions arithm�tiques simples (notre Pascaline � nous).

chainl et chainl1 prennent en argument deux analyseurs : un qui permet d�obtenir les termes de l�op�ration (Parser a), un autre qui permet d�obtenir l�op�ration elle-m�me (Parser (a -> a -> a)). Il reposent sur le m�me principe de co-r�cursion et de gestion d��chec par l��l�ment neutre et l�addition.

chainl :: Parser a -> Parser (a -> a -> a) -> a -> Parser a
chainl p op a = chainl1 p op +++ return a
chainl1 :: Parser a -> Parser (a -> a -> a) -> Parser a
p `chainl1` op = do { a <- p; rest a}

where rest a = do { f <- op; b <- p; rest (f a b) } +++ return a

L�interpr�teur
Maintenant vous en savez assez pour comprendre le code suivant. La beaut� r�side dans sa forme tr�s proche d�une grammaire au format Backus-Naur (les d�clarations de type sont plac�es en premier pour le faire ressortir ensuite):
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
expr :: Parser Int
term :: Parser Int
factor :: Parser Int
digit :: Parser Int
symb :: String -> Parser String
addop :: Parser (Int -> Int -> Int)
mulop :: Parser (Int -> Int -> Int)
 
-- BNF GRAMMAR
 
expr = term `chainl1` addop
term = factor `chainl1` mulop
factor = digit +++ do { symb "("; n <- expr; symb ")"; return n }
 
symb cs = string cs
digit = do { x <- sat isDigit; return (ord x - ord '0') }
 
addop = do { symb "+"; return (+) } +++ do { symb "-"; return (-) }
mulop = do { symb "*"; return (*) } +++ do { symb "/"; return div }
> parse expr "1+1-1*1"
[(1, "")] -- CQFD

Conclusion
La courbe d�apprentissage des langages fonctionnels est assez raide. Ce billet utilise un certain nombre de concepts nouveaux et la tournure d�esprit est tr�s diff�rente de celle d�un langage imp�ratif. N�anmoins, une fois surmont� cet obstacle, la modularit�, l�extensibilit� et la g�n�ralit� des constructions devient �vidente. Avec les primitives d�crites ici on peut facilement �crire un interpr�teur pour un autre langage, un lecteur de fichiers html ou csv, etc. Je joins un code source consolid� (au format txt � convertir en .hs, qui n�est pas autoris� comme PJ par le site :( ) pour ceux qui souhaiteraient exp�rimenter. parser-1.txt

Je profiterai de cette possibilit� dans un des prochains billets pour pr�senter quelques concepts basiques de logique propositionnelle. Je compte �galement m�appesantir un peu sur les mono�des et pr�senter quelques structures de donn�es fonctionnelles int�ressantes.

P.S : les questions, commentaires, suggestions, corrections, etc. sont les bienvenus!!

Exercices :
- lire l�article d�origine
- adapter le programme pour prendre en compte la possibilit� d�espaces entre les chiffres (ex : "1 + 1 � 1 * 1")
- ajouter les nombres de plusieurs chiffres
- ajouter la possibilit� d��lever un nombre � une puissance n

En qu�te de feedback...

stendhal666 — Wed, 29 Apr 2015 07:18:37 GMT

Voici le quinzi�me billet de ce blog et je suis saisi de doutes... Quelqu'un a-t-il des conseils sur la direction � prendre?

Quelques id�es pour la suite
Venant d'introduire les monades, je comptais par la suite en montrer quelques applications: comment repr�senter le hasard dans un contexte fonctionnel pur? comment effectuer �l�gamment l'analyse lexicale (le "parsing") d'une cha�ne de caract�res? Je voulais introduire �galement d'autres cat�gories: foncteurs, endo-foncteurs, mono�des et montrer leurs relations, structurelles ou fonctionnelles. Enfin, j'avais d'autres id�es diverses: pr�sentation de structures de donn�es utiles en programmation fonctionnelle, traduction de certains papiers de recherche ou billets de blog...

Mes doutes et questions
Est-ce que ces directions int�ressent mes aimables lecteurs? Est-ce que d'autres leur paraissent plus pertinentes? Ont-ils des r�serves sur la programmation fonctionnelle et demandent que soient �claircis certains points? Au contraire, les billets sont-ils trop basiques ou trop fragment�s?

Conclusion
Vous l'avez compris, je suis en qu�te de feedback. Merci d'avance � ceux qui voudront bien laisser quelques conseils en commentaire!

Jack Bauer et les monades

stendhal666 — Mon, 27 Apr 2015 12:44:13 GMT

Attention, ceci n�est pas la saison 8 de 24H. Vous y trouverez en revanche une r�flexion palpitante sur les mod�les de gestion des exceptions � disposition du programmeur, dans l�esprit du billet pr�c�dent. Je commencerai par le r�sumer en quelques phrases car je crains que l�aridit� du titre et la longueur du d�veloppement n�en aient d�courag� certains. J�en recommande n�anmoins la lecture, pour son int�r�t intrins�que et le dur travail que m�a demand� sa traduction.

Pr�c�demment, dans func�programming�
La th�orie des cat�gories permet de formuler, de fa�on consciente et explicite, les concepts, restrictions et �-peu-pr�s qui fa�onnent un langage de programmation. En effet, les � fonctions � qui y sont utilis�es, loin d��tre de simples fonctions math�matiques, y sont des outils de puissance variable qui autorisent �ou non, et de fa�ons diff�rentes- la gestion des erreurs, l�interaction avec le monde ext�rieur ou la r�f�rence � des param�tres globaux : elles sont donc mieux d�crites comme composant des � cat�gories �, au sens de la th�orie des cat�gories.

Les fl�ches de Kleisli sont l�abstraction de la th�orie des cat�gories la plus imm�diatement applicable aux langages de programmation : alors qu�une fonction math�matique associe un ensemble A � un ensemble B, la fl�che de Kleisli associe un ensemble A � un ensemble K(B), o� K ajoute un suppl�ment d��me � B : la gestion des erreurs, l�interaction avec le monde ext�rieur, etc. Reste � d�finir un nouvel op�rateur de composition, car, si a -> b et b -> c se composent naturellement, a -> K(b) et b -> K(c) ne le peuvent pas.

Les cat�gories utilis�es dans la plupart des langages de programmation sont fix�es par le standard et ne peuvent pas �tre modifi�es, obligeant � respecter des conventions parfois � la limite de la lisibilit�. Un langage comme Haskell, qui permet de manipuler les abstractions de la th�orie des cat�gories, l�ve cette restriction et permet de cr�er les cat�gories les plus adapt�es � la t�che envisag�e.

Jack Bauer
Jack Bauer doit retrouver les codes qui emp�cheront une bombe nucl�aire d�exposer au c�ur de Los Angeles. Pour cela, il doit mettre la main sur un mercenaire immoral, qui lui donnera l�adresse d�un terroriste, qui d�tient quelque part une pirate informatique tr�s jolie, qui a cach� dans la consigne d�une gare les codes en question. A premi�re vue :

if ( prendreCodes(cachetteDeLaPirate(adresseDuTerroriste(repaireDuMercenaire()))) == CODE ) print � Ouf !� else print � Boom ! �

N�anmoins, il y a une bonne chance que Jack Bauer, � cause de sa fille, �choue dans l�une de ces t�ches�

MacGyver : scotch, ficelle et bo�te d�allumettes
C�est l�option du langage C. On n�a pas d�outil sp�cial pour la gestion des exceptions, alors on fait avec ce qu�on a sous la main. Premi�re solution : renvoyer une valeur conventionnelle pour l��chec, comme NULL, -1, etc. Je ne m��tendrai pas trop sur les d�fauts de cette m�thode, je pense que tout le monde est au courant. Seconde solution : la valeur de retour est un bol�en qui indique s�il y a �chec, et le v�ritable retour est plac� dans un param�tre � modifier :
Code C : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
char* repaire ;
if (repaireDuMercenaire(repaire)) {
  char* adresse ;
  if (adresseDuTerroriste(repaire, adresse) {
     char* cachette ;
     if (cachetteDeLaPirate(adresse, cachette)) {
        long codes ;
        if (prendreCodes(cachette, &codes) {
           if (codes == CODES) printf(« OUF ! ») ; else printf(« Boom ») ;
        }
        else printf (« Boom ! ») ;
      }
      else printf (« Boom ! ») ;
    }
     else printf (« Boom ! ») ;
  }
   else printf (« Boom ! ») ;
}
else printf (« Boom ! ») ; // ce else est en trop, mais il faut compter pour s'en apercevoir...
C�est une solution qui marche, mais� Disons que de temps en temps, plut�t que d�improviser une montgolfi�re miniature, on pr�f�rerait prendre l�ascenseur.

James Bond : une voiture qui vole
La deuxi�me solution est d�ajouter des features au langage. On a une voiture, on voudrait voler, on ach�te une voiture qui vole. On a des fonctions C, on voudrait g�rer les exceptions de fa�on structur�e, on passe � C++. Chacune des fonctions contient un garde-fou : si l�action �choue, on balance une exception et on court-circuite l�ex�cution du programme jusqu�� la clause de gestion des exceptions (le catch).

Cette solution est largement pr�f�rable � la premi�re. La solution �vidente :

if ( prendreCodes(cachetteDeLaPirate(adresseDuTerroriste(repaireDuMercenaire()))) == CODE )

n�est toujours pas possible, puisqu�il faut au moins un try quelque part. Mais un code comme :
Code C++ : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
try {
  long codes = prendreCodes(cachetteDeLaPirate(adresseDuTerroriste(repaireDuMercenaire())))
  std : :cout << (codes == CODE ? « ouf ! » : « boom ! ») ;
}
catch (…) {
  std : :cout << « Aaargh ! Kim Bauer a encore frappé ! »
}
est tout de m�me lisible et robuste.

L�inconv�nient est qu�il a fallu r��crire tout le programme en C++ et que, entre temps, Los Angeles est devenue un ville fant�me. Plus s�rieusement, la gestion des exceptions a son c�t� obscur (voir ce billet, par exemple) et ses difficult�s (voir celui-l�). C�est un de ces domaines o� l�exp�rience ne s�ach�te pas.

Haskell : la monade des � peut-�tre �
Comme j�introduis la premi�re fois, sous l�angle technique, l�utilisation de la th�orie des cat�gories, j�utiliserai la fa�on la plus simple de g�rer les exceptions �mais un m�canisme plus puissant demanderait des modifications mineures.

Adoptons l�approche d�velopp�e dans le billet pr�c�dent : la premi�re �tape est de d�crire ce que serait le domaine d�arriv�e d�une fonction susceptible d��chec ; la r�ponse est qu�il s�agit de l�ensemble des �l�ments de succ�s et, a minima (c�est notre approche aujourd�hui), d�un �l�ment d��chec. Cr�ons un type pour repr�senter ce domaine d�arriv�e :

data PeutEtre a = Juste a | Rien --� noter qu�un constructeur de type, pas une valeur, repr�sente l��chec

par exemple, la fonction retournant l�adresse du terroriste aurait pour type :

adresseDuTerroriste :: String -> PeutEtre String

Elle prend en argument le repaire du mercenaire, et si Jack torture suffisamment cruellement le mercenaire, elle retourne Juste adresse, sinon Rien. N�anmoins, la fonction cachetteDeLaPirate a �galement pour type :

cachetteDeLaPirate :: String -> PeutEtre String

On ne peut donc pas lui donner directement la valeur de retour de adresseDuTerroriste�

Composition et identit�
Vient la deuxi�me �tape d�crite dans le billet pr�c�dent : indiquer comment se font la composition et l�identit� :

compose : : PeutEtre a -> (a -> PeutEtre b) -> PeutEtre b

Rien de trop compliqu� : si on re�oit Rien, le r�sultat est forc�ment Rien ; si on re�oit Juste x, alors le r�sultat est f x :
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
compose Rien _ = Rien
compose (Juste x) f = f x
Voil� pour la composition. L�identit� est la fonction qui associe � x dans A, x dans K(A). Elle est encore plus simple � d�finir.
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
identity : : a -> PeutEtre a
identity x = Juste x
En effet, Rien n�existe pas dans A ; donc tout �l�ment de A est n�cessairement un succ�s, un Juste x.

Monade, classe et syntaxe
Les monades sont en Haskell une classe de type, ou typeclass (pour un rappel de ces notions, voir ce billet). Elle est d�finie de la fa�on suivante :
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
class Monad m where
  return :: a -> m a --identity
  (>>=) : : m a -> (a -> m b) -> m b  --compose
Notre monade PeutEtre pourrait donc �tre d�finie de la fa�on suivante :
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
instance Monad PeutEtre where
	return = identity
	(>>=) = compose
Nous pouvons donc exprimer la qu�te de Jack de la fa�on suivante :

repaireDuMercenaire >>= adresseDuTerroriste >>= cachetteDeLaPirate � --oh shit !

C�est un bon d�but, mais il reste � comparer les codes obtenus avec les codes corrects. Or le comparateur (==) prend deux arguments de type identique, et j�ai un PeutEtre Code d�un c�t�, un Code de l�autre. Il faut donc que je puisse lier le code contenu dans le PeutEtre � une variable, afin de le comparer au code correct. Nouvel essai :

repaireDuMercenaire >>= adresseDuTerroriste >>= cachetteDeLaPirate >>= \code -> � --oh shit !

Mais il faut encore que le r�sultat de la comparaison soit un PeutEtre, si je veux respecter le type de compose� Heureusement nous avons identity pour cela, ouf !

repaireDuMercenaire >>= adresseDuTerroriste >>= cachetteDeLaPirate >>= \code -> return (code == CODE)

Pour r�capituler :
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
queSestIlPasse (Juste True) = « Ouf ! »
queSestIlPasse (Juste False) = « Boom ! »
queSestIlPasse Rien = « Aaargh ! Kim Bauer a encore frappé »
 
resumeDeLEpisode = printLn $ queSestIlPasse (repaireDuMercenaire >>=  adresseDuTerroriste >>= cachetteDeLaPirate >>= \code -> return (code == CODE))
Conclusion :
Voici une premi�re monade, toute simple. Elle existe d�j� dans la biblioth�que standard d�Haskell, sous le nom de Maybe. L�important, plus que l�impl�mentation (on l�a vu, rien de tr�s difficile), est d�avoir pu cr�er un syst�me de gestion des exceptions en quelques lignes de code, sans support sp�cifique du langage.

Exercices :

- d�finir une nouvelle monade, pour un type :
data Try a = Succes a | Exception String
qui renvoie soit Succes a si tout s�est bien pass�, soit Exception messageDErreur
- une liste est-elle une monade ? Justifiez
- si vous ne l�avez pas d�j� fait, lisez le billet pr�c�dent

A quoi peuvent bien servir les monades?

stendhal666 — Fri, 24 Apr 2015 09:38:27 GMT

Ce billet est la traduction d'un billet �crit en anglais par cdsmith: Why do Monads Matter?

Th�orie des cat�gories et programmation : correspondance parfaite ou distraction abstraite ?
Si vous �tes un d�veloppeur : avez-vous entendu parler des monades ? Vous �tes-vous demand� de quoi il s�agissait ? Avez-vous tent� d�apprendre Haskell et lutt� avec cette notion ? Avez-vous regard� des vid�os de � Channel 9 � o� un tas de chercheurs de Microsoft en parlent, mais ont du mal � faire le lien avec votre exp�rience de tous les jours ?

Si vous �tes un math�maticien : avez-vous entendu parler l�int�r�t de la th�orie des cat�gories pour la science informatique ? Avez-vous cherch� un �nonc� clair des raisons de cet int�r�t ? Dout� qu�il y en ait de satisfaisantes ? Peut-�tre que, comme un de mes amis qui m�a interrog� � ce sujet il y a un an, vous vous rappelez avoir entendu que la th�orie des cat�gories avait suscit� beaucoup d�excitation dans la recherche informatique des ann�es 90, mais n�avez jamais su si c��tait une impasse ou si cela avait d�bouch� ?

C�est le genre de questions auxquelles je vais r�pondre. Mon but est de d�montrer, pr�cisions et exemples � l�appui:
- d�o� viennent les id�es et intuitions relatives � la th�orie des cat�gories en informatique
- pourquoi le futur de la programmation repose sur ces id�es, et pourquoi les ignorer, comme le font les langages les plus r�pandus, est dommageable
- quel est l��tat de l�art dans l�application de la th�orie des cat�gories aux probl�mes pos�s par l�informatique

Si vous vous lancez dans cet article sans aucune notion sur la th�orie des cat�gories, n�ayez pas peur ! C�est une des introductions les plus progressives aux cat�gories et aux monades que vous pourrez trouver. Cependant, lisez lentement pour bien comprendre la d�finition des cat�gories et des id�es connexes, comme la composition de fonction, qui sont cruciales. Par ailleurs, vous pouvez passez outre ou rapidement sur la section � Quel est le rapport avec les monades ? � o� j�explique en quoi le sujet correspond au sens donn� traditionnellement aux monades par les math�matiques : il n�est pas vraiment n�cessaire de le savoir.

En revanche, si vous �tes math�maticien, vous pouvez laisser tomber les rappels basiques sur la th�orie des cat�gories et approfondir plut�t les passages o� j�adopte la perspective des sciences informatiques. Attention tout de m�me, j�introduis les monades via les cat�gories de Kleisli, donc prenez le temps de vous assurer que vous �tes familiers de la relation entre les deux.

Pr�ts ? Allons-y !

Programmation informatique et fonctions : une relation t�nue.
Question rapide : les programmeurs utilisent-ils des fonctions ?
Demandez � n�importe quel programmeur, il vous r�pondra : OUI ! Les fonctions sont un des outils les plus basiques de la programmation. Vous aurez droit � un regard atterr� : bien s�r ! Autant demander si les charpentiers utilisent des clous, non ?

La v�rit� est pourtant un peu plus compliqu�e. Pour un math�maticien, une fonction associe simplement des valeurs d�entr�e et des valeurs de sortie� et c�est tout ! Deux fonctions qui associent les m�mes valeurs d�entr�e aux m�mes valeurs de sortie sont identiques. Vous pouvez repr�senter des fonctions par des formules, mais aussi, simplement, par des tables d�entr�e/sortie, ou par des graphes s�il s�agit de nombres r�els. Si vous demandez des exemples de fonctions � des programmeurs, pourtant, ils seront bien diff�rents : pour les appeler des fonctions, il faudrait avoir rat� le cours d�analyse. Ce sont des choses que les programmeurs appellent sans arri�re-pens�e des fonctions, mais qui n�en sont pas du tout pour les math�maticiens :
- des � fonctions � qui renvoient des nombres choisis au hasard� et donneront des r�sultats diff�rents � chaque appel ;
- des � fonctions � qui renvoient une r�ponse le dimanche, mais une autre le lundi, encore une autre le mardi, et ainsi de suite ;
- des � fonctions � qui font appara�tre des mots sur l��cran d�un ordinateur � chaque calcul d�une valeur.

Qu�est-ce que cela peut bien vouloir dire ? La plupart des programmeurs vivent paisiblement en appelant ces choses des fonctions, alors qu�elles en sont bien diff�rentes. Mais une seconde ! Ces deux notions ont quand m�me beaucoup en commun. En particulier : (a) des param�tres, qui repr�sentent leur domaine de d�part et (b) des valeurs de retour, qui repr�sentent leur domaine d�arriv�e (bien des programmeurs parlent de fonction qui n�ont ni argument, ni valeur de retour� mais pas la peine d��tre pointilleux, il suffit de regarder leurs domaines de d�part et d�arriv�e comme des ensembles � un �l�ment, et on sauve les apparences)

Encore plus important, ces � fonctions � ont en commun avec les fonctions math�matiques d��tre constamment compos�es, en prenant en param�tre le r�sultat d�une autre fonction. Quand je parle de composition, c�est presqu�exactement au sens math�matique : (f . g) (x) = f(g(x)). D�ailleurs, la raison pour laquelle les fonctions existent est pour pouvoir les composer entre elles ! Autrefois, dans les premiers temps de l�informatique, on se satisfaisait de garder trace d�une information en la stockant � un endroit d�termin� de la m�moire; mais devoir garder trace de tous ces emplacements compliquait l��criture s�par�e des parties d�un programme pour les assembler ensuite ; on est donc pass� � l�utilisation de fonctions et de leur composition.

R�capitulons une premi�re fois :

Quand les programmeurs parlent de fonctions, il s�agit d�un concept diff�rent de celui des math�maticiens.
Ce qu�ils entendent c�est : des valeurs d�entr�e (le domaine d�entr�e) et des valeurs de retour (domaine d�arriv�e), et encore plus important, la composition de ces objets.

Puis vint la th�orie des cat�gories�
Nous avons conclu la section pr�c�dente les mains pleines de choses qui ressemblent � des fonctions, qui ont des domaines d�entr�e et d�arriv�e, et peuvent �tre compos�es. Pour autant, elles diff�rent des fonctions au sens math�matique. D�concertant ? Non, pas vraiment. Les math�maticiens connaissent bien cela : ils ont un nom pour les syst�mes d�objets � fonctionnesques � de ce genre, et ce nom est � roulement de tambours� CATEGORIES !

Dans le jargon math�matique, les cat�gories sont :
- des collections � d�objets � (pensez � des ensembles),
- et de � fl�ches � (pensez � des fonctions entre les ensembles)
- o� chaque fl�che a une domaine d�entr�e et de sortie
- chaque objet a une fl�che � identit� � (pensez � la fonction d�identit� f(x) = x
- et o� les fl�ches peuvent �tre compos�es quand les domaines d�arriv�e et d�entr�e correspondent

Avant d�accepter quelque chose comme une cat�gorie, il faut ajouter quelques r�gles : une fonction compos�e avec la fonction d�identit� ne change pas, et la composition de fonctions ob�it � la loi d�associativit�. Cela n�est en soi pas surprenant, donc si cela devait vous para�tre �trange, prenez un stylo, travaillez la d�finition de la composition de fonctions ( (f . g) (x) = f(g(x)) ) et simplifiez.

Voil� l�int�r�t des cat�gories : ce n�est pas une abstraction invent�e sans but par une bande de math�maticiens. Les cat�gories sont d�finies de cette fa�on parce qu�on a remarqu� que des centaines d�objets ressemblaient � des fonctions, avec des domaines d�entr�e et de sortie et des compositions. Des objets de l�alg�bre, comme les groupes, les anneaux et les espaces vectoriels ; des objets de l�analyse, comme les espaces m�triques et topologiques ; des objets de l�analyse combinatoire, comme les �l�ments d�ensembles partiellement ordonn�s ou les chemins des graphes ; des objets de la logique formelle, comme les preuves et les propositions. Ces objets peuvent presque tous �tre d�crits avec les id�es que nous venons de voir ! En bref, les cat�gories sont l�intuition juste pour traiter des objets qui ont un domaine d�entr�e et de sortie et se composent. Et c�est justement ce que nous cherchons � faire.

Les quatre cavaliers de la Catapocalypse
Vous voyez maintenant ce que viennent faire ici les cat�gories : elles sont l�intuition juste de choses qui ne sont peut-�tre pas des fonctions, mais peuvent �tre compos�es comme des fonctions. Plus encore, ces id�es de la th�orie des cat�gorie r�pondent � des probl�mes rencontr�s par les d�veloppeurs informatiques.

Il est temps d��tre plus sp�cifique et d�introduire les quatre exemples qui nous guideront dans notre exploration. Chaque exemple illustre une fa�on dont les � fonctions � utilis�es par les programmeurs diff�rent des fonctions des math�maticiens. Ces exemples reprennent des probl�mes r�els rencontr�s par les programmeurs. Nous reviendrons sur l�aspect pratique de la question mais, pour l�instant, prenons le temps de nous familiariser avec chacun d�entre eux .

Le premier cavalier : l��chec.
Le premier probl�me est celui de l��chec. Un programmeur tente souvent des choses qui peuvent �chouer. Lire un fichier (il peut ne pas exister, on peut �tre priv�s des droits d�acc�s), communiquer par Internet (le r�seau peut �tre coup� ou trop lent), et m�me faire de bons vieux calculs avec une grande quantit� de donn�es (on peut manquer de m�moire). En cons�quence, l��chec est un souci constant.

En g�n�ral, les outils modernes de programmation informatique comptent sur la possibilit� d��chec d�une fonction. Vous pouvez disposer d�une valeur de retour, mais vous pouvez aussi recevoir une raison pour l��chec de la t�che demand�e. Quand cela se produit, le programmeur est responsable de la r�ponse � apporter : avertir quelqu�un, nettoyer la m�moire de l�ordinateur, ou parfois remettre les choses en �tat pour continuer. La fa�on dont ils permettent de traiter la possibilit� constante d�un �chec est un �l�ment majeur dans le choix des techniques et des outils de d�veloppement.

Le deuxi�me cavalier : la d�pendance
Le deuxi�me cavalier est la d�pendance � des informations ext�rieures. Tandis que les fonctions des math�maticiens ne d�pendent que de leurs arguments, les programmeurs n�ont pas ce luxe. Les applications sont souvent un cauchemar de param�tres de configuration. M�me les t�l�phones mobiles les plus simples ont des pages et des pages de param�tres : quelle est la langue de l�utilisateur ? la fr�quence de sauvegarde ? faut-il crypter les communications ? Rares sont les applications qui n�ont pas un menu � param�tres � ou � pr�f�rences �. Dans bien d�autres contextes, les programmes d�pendent d�informations qui sont un genre de � savoir partag� � de l�application ou d�une partie de celle-ci.

La fa�on de traiter la question a �volu� � travers les �ges. Quand l�information �tait de toute fa�on rang�e dans des r�gions bien connues de la m�moire, il �tait assez facile de la retrouver ; mais cela conduisait � d�autres probl�mes quand diff�rentes parties du programme devaient stocker diff�rentes informations et pouvaient se marcher sur les pieds. La technique extr�mement influente de la programmation orient�e objet peut �tre vue, au moins partiellement, comme une tentative de r�solution du probl�me, par le regroupement de fonctions dans un objet contenant le contexte dont elles d�pendent� mais quand les d�pendances sont nombreuses, passer tout ces param�tres n�a plus rien de pratique.

Le troisi�me cavalier : l�incertitude
Le troisi�me probl�me est l�incertitude, ou encore non-d�terminisme. Une fonction normale associe une valeur d�entr�e et une valeur de sortie. Une fonction non-d�terministe associe une valeur d�entr�e � un certain nombre de valeurs de sorties possibles. Le non-d�terminisme est moins bien connu que les deux premiers probl�mes, mais peut-�tre parce qu�il n�a pas encore �t� r�solu par un langage g�n�raliste !

En effet, si la science informatique th�orique traite abondamment du sujet, parce que c�est l�approche adapt�e � un grand nombre de probl�mes tels que l�analyse syntaxique, la v�rification ou simplement les recherches, il n�a pas encore fait son chemin dans la pratique informatique.
Le non d�terminisme appara�t lorsque de multiples r�ponses peuvent correspondre � une requ�te ou une recherche, c�est-�-dire pr�cis�ment l� o� le programmeur finit par d�pendre d�outils ext�rieurs comme SQL, Prolog ou, plus r�cemment, LINQ et d�autres technologies int�gr�es au langage.
Et lorsqu�une t�che ne para�t pas justifier l�utilisation d�un outil calibr� pour le requ�tage intensif ou les recherches, on finit par �crire ses propres boucles imbriqu�es et des structures de contr�les pour parcourir tous les possibles. Ce genre de situation est responsable de structures de code parmi les plus complexes qu�on puisse rencontrer aujourd�hui.

Tandis que les deux premiers probl�mes, �chec et d�pendance, ont �t� en partie r�solus par des langages couramment utilis�s, ce probl�me est trait� principalement au moyen de sous-langages sp�cialis�s, � la notable exception de LINQ.

Le quatri�me cavalier : destruction.
Le quatri�me probl�me est la destruction. Evaluer une fonction math�matique a pour seul effet d�obtenir la valeur retour. Mais dans un programme, les fonctions peuvent avoir un effet permanent sur le reste du monde : afficher une information, attendre les r�ponses d�autres ordinateurs, imprimer des documents et m�me envoyer des missiles, pour des syst�mes militaires ! En cons�quence, des points qui n�ont pas besoin d��tre pr�cis�s en math�matiques, comme l�ordre d��valuation, restent tr�s importants.

La nature destructrice (par quoi j�entends : qui a des effets irr�versibles) des programmes informatiques a de nombreuses cons�quences. Elle augmente le nombre d�erreurs commises. Elle rend plus difficile de diviser une t�che et de l�accomplir simultan�ment en plusieurs endroits, comme on pourrait vouloir le faire sur un ordinateur multi-c�ur moderne, parce que l�ordre dans lequel on le fait peut �tre incorrect. Mais d�un autre c�t�, la destruction est justement l�int�r�t premier de la programmation : une application qui n�aurait pas d�effet observable ne vaudrait pas la peine d��tre lanc�e ! Donc nos fonctions doivent affronter la question de la destruction, dans tous les langages couramment utilis�s.

Retour aux fonctions
Nous avons inspect� des probl�mes trouv�s dans le monde informatique : le d�veloppement de logiciels qui peuvent �chouer, doivent g�r�r plein de param�tres contextuels, mod�lisent des choix non-d�terministes et ont parfois des effets sur les monde qui contraignent l�ordre des calculs.

Il peut sembler que nous sommes tr�s loin du monde simple et gentil des math�matiques. Et pourtant ! En y regardant de plus pr�s �et en louchant suffisamment- chacune de ces quasi-fonctions peut �tre reconnue, apr�s tout, comme une bonne petite fonction bien �lev�e. Il y a un co�t, n�anmoins : pour les transformer en de v�ritables fonctions nous devons modifier leur domaine d�arriv�e. Voici comment cela fonctionne pour chacun des cavaliers.

Fonctions et �chec
Notre premier exemple �tait les fonctions qui peuvent �chouer. Il n�est pas si difficile de voir qu�une fonction susceptible d��chec est en fait une fonction dont le r�sultat inclut :
- des succ�s, qui sont les r�sultats possibles et attendus
- des �checs, qui d�crivent la raison de l��chec

Donc pour tout ensemble A, nous pouvons d�finir un nouvel ensemble Err(A) qui contient A et les diff�rentes raisons pour lesquelles l��chec est possible. Une fonction susceptible d��chec avec un domaine d�entr�e A et un domaine d�arriv�e B est en fait une fonction de A vers Err(B).

Fonctions et d�pendance
Nos deuxi�mes pseudo-fonctions sont celles qui d�pendent d�informations ext�rieures, comme les param�tres d�une application. Nous utilisons ici une astuce similaire : pour un ensemble A, nous d�finissons un ensemble Param(A) qui est l�ensemble des fonctions partant des param�tres de l�application pour parvenir � l�ensemble A. D�s lors, une fonction � � contexte � de A � B est une fonction ordinaire de A � Param(B). Autrement dit, vous lui donnez une valeur issue de A et elle vous rend une fonction qui lie les param�tres de l�application � l�ensemble B.

Aussi d�concertant que cela puisse para�tre, une fonction dont le domaine d�arriv�e est une autre fonction est simplement une fonction � deux arguments, � l�exception du fait qu�elle prend ses arguments un � la fois ! Prenez une minute pour vous en convaincre. La conversion entre ces deux id�es �quivalentes est parfois appel�e � currying �. Donc en modifiant le domaine d�arriv�e de cette fonction, nous lui avons en fait adjoint un nouveau param�tre : les pr�f�rences enregistr�es par l�application. Bien que ce ne soit pas tr�s pratique (nous couvrirons cet aspect plus tard) , c�est exactement ce que nous souhaitions.

Fonctions et incertitude
C�est peut-�tre l�exemple le plus facile � r�soudre. Notre troisi�me type recouvrait les fonctions qui repr�sentent le non-d�terminisme : au lieu d�une r�ponse d�termin�e, elles renvoient toutes celles qui sont possibles. Il suffit donc de d�finir, pour tout ensemble A, P(A) comme l�ensemble des sous-ensembles de A. Une fonction non-d�terministe de A � B est une fonction ordinaire de A � P(B).

Fonctions et destruction
Nous devons enfin traiter les fonctions qui ont un effet destructeur. Notre r�ponse sera un peu plus �labor�e : pour tout ensemble A, nous d�finissions IO(A) (pour input/output, qui correspond � la notion d�effets r�sultant de l�interaction avec le reste du monde). Un �l�ment de l�ensemble IO(A) est une liste d�instructions pour obtenir un membre de A : ce n�est donc pas un membre de A, mais plut�t la fa�on d�en obtenir un, et cette proc�dure peut avoir un nombre quelconque d�effets observables.

Nous utilisons la m�me astuce et modifions le domaine d�arriv�e : une fonction destructrice de A � B est une fonction math�matique ordinaire de A � IO(B). Autrement dit, si vous me donnez un A, comme je suis une simple fonction math�matique, je ne peux pas parcourir les �tapes jusqu�� B mais je peux vous dire lesquelles il faut respecter.

Mais qu�en est-il de la composition ? C�est merveilleux d��tre de retour dans le monde simple des fonctions, mais vous souvenez-vous de ce qui nous y a conduit ? Nous voulions des fonctions parce que nous voulions pouvoir les composer, mais il semble que ce ne soit plus possible ! J�avais des fonctions, susceptibles d��chec, de A � B et de B � C, je les ai �chang�es contre des fonctions de A � Err(B) et de B � Err(C) et les domaines ne correspondent plus, je ne peux plus les composer !

Oh non !

Retenez vos montures, Heinrich Kleisli arrive � la rescousse
Bon, tout n�est pas perdu, c�est juste que je n�ai pas dit encore comment composer ces fonctions � sp�ciales �.

Parce qu�un matheux a d�couvert ces choses avant nous, on les appelle par son nom : ce sont les fl�ches de Kleisli. Faites attention parce qu�il y a deux choses � garder � l�esprit : premi�rement, les fl�ches de Kleisli sont de bonnes vieilles fonctions, on peut les composer comme des fonctions et c�est parfait; mais en m�me temps elles sont � sp�ciales � et on peut �galement les composer comme des fl�ches de Kleisli.

Vous vous souvenez de ce qu�on avait dit ? La bonne fa�on de penser la composition est de penser par cat�gorie. Les ensembles sont une cat�gorie, et c�est celle qu�utilise les fonctions math�matiques. Mais nous voulons un autre genre de cat�gorie d�sormais, appel�e cat�gorie de Kleisli. Si vous avez oubli� la d�finition des cat�gories, c�est le moment de la revoir. Pour d�finir une cat�gorie, on a besoin d�objets, de fl�ches, d�identit�s et de composition.

Pour rester simple, les objets de la nouvelle cat�gorie seront les m�mes : ce sont juste des ensembles de choses.
Les fl�ches, sans surprise, sont des fl�ches de Kleisli.

Je ne vous ai pas encore dit � quoi ressemblent les identit�s et la composition, alors voici :

Commen�ons par l��chec : soient une fl�che de Kleisli � �chec � de A � B, et une de B � C. Nous cherchons � les composer en une fl�che Kleisli de A � C. En d�autres mots, nous avons une fonction ordinaire de A � Err(B) et une autre de B � Err(C) et nous en cherchons une qui va de A � Err(C). Prenez une minute pour y r�fl�chir.

L�id�e centrale de la gestion des erreurs est que si la premi�re fonction donne une erreur, il faut s'arr�ter et d�clarer l�erreur. C�est seulement si la premi�re fonction r�ussi qu�il faut passer � la seconde, et donner le r�sultat (qu�il s�agisse d�un succ�s ou d�un �chec). Pour r�sumer :

Si g(x) donne une erreur, alors (f . g)(x) = g(x)
Si g(x) r�ussit, alors (f . g)(x) = f(g(x))

Pour achever la d�finition d�une cat�gorie, nous devons choisir les fl�ches de Kleisli � identit� �. Ce sont celles qui ne font rien du tout, donc qu�on peut composer avec une autre fl�che sans la modifier. Les identit�s sont des fonctions de A vers Err(A) et il se trouve qu�elles sont simplement en l�occurrence les fonctions f(x) = x, comme pour les ensembles. Remarquez qu�elles ne renvoient jamais d��chec, mais toujours des succ�s.

Je passerai plus rapidement sur les trois exemples suivants, mais j�encourage les lecteurs qui ne trouvent pas le sujet encore assez clair � les travailler plus en d�tail et � utiliser cette opportunit� de se familiariser avec la d�finition d�une fl�che de Kleisli.

Pour les fl�ches de Kleisli � d�pendance �, qui sont des fonctions de A � Param(B), souvenez-vous qu�elles �quivalent � ajouter un param�tre repr�sentant les pr�f�rences de l�application. L�id�e ma�tresse est que, si mes deux fonctions ont besoin de conna�tre les pr�f�rences de l�application, je dois donner le m�me param�tre aux deux. Donc composer ces deux fl�ches de Kleisli construit une nouvelle fonction qui re�oit les pr�f�rences comme param�tre et les transmet � ses deux composantes. Quant aux identit�s, il s�agit de fl�ches de Kleisli qui re�oivent le param�tre � pr�f�rences � mais l�ignorent et renvoient leur valeur d�entr�e.

Les fl�ches de Kleisli � incertitude � ou � non-d�terminisme � sont des fonctions de A � P(B), l�ensemble des sous-ensemble de B. Cette fois-ci l�id�e est d�essayer toutes les valeurs g�n�r�es � chaque �tape et de collecter l�ensemble des r�sultats. Donc la composition calcule la deuxi�me fonction pour chacun des r�sultats de la premi�re et les r�sultats sont fusionn�s par union des ensembles. Les identit�s, bien s�r, ne sont pas r�ellement non-d�terministes mais retournent des ensembles d�un �l�ment contenant leur valeur d�entr�e.

Enfin, les fl�ches de Kleisli pour les effets destructeurs sont des fonctions de A � IO(B). L�, l�id�e est de combiner les instructions en les suivant �tape par �tape : la premi�re d�abord, puis la suivante. Donc la composition consiste � �crire les instructions n�cessaires � la premi�re action, puis � la deuxi�me, dans cet ordre. Une fl�che de Kleisli � identit� � est l�instruction de ne rien faire et de renvoyer la valeur d�entr�e comme r�sultat.
Ainsi, pour chacun de ces probl�mes, nous avons cr�� une nouvelle cat�gorie de Kleisli.

Ces nouvelles cat�gories ont chacune en propre leurs identit�s, composition et autres aspects des fonctions, qui expriment la nature d�un probl�me sp�cifique. En utilisant la notion de composition dans la fl�che de Kleisi appropri�e, vous pouvez r�soudre n�importe lequel de ces probl�mes anciens de l�informatique de fa�on ais�e et modulaire.

Et voil� la raison pour laquelle il faut s�int�resser aux monades.

Aux monades ? ? ! Ah, oui, il faut quand m�me que je pr�cise que vous venez de d�couvrir les monades. Simplement sans utiliser le mot.

Quel est le rapport avec les monades ?
Cette section est destin�e � ceux qui veulent conna�tre les relations entre ce que nous venons de d�crire et les monades telles qu�elles sont d�finies en math�matiques. Si vous ouvrez Wikipedia ou un manuel de th�orie des cat�gories, ce que vous y rencontrerez sera assez diff�rent de ce que nous venons de voir. Vous entendrez parler d�endo-foncteurs, de deux transformations naturelles et de propri�t�s de commutation entre triangles et carr�s.

Nous n�avons pas du tout parl� de foncteurs, et encore moins de transformations naturelles� donc comment aurions-nous pu apprendre ce que sont les monades ? Il s�av�re qu�il existe plus d�une fa�on de d�crire les monades. Celle que nous avons utilis�e est tout � fait valide. Les d�placements que nous avons fait subir aux domaines d�arriv�e de nos fonctions �Err, Param, P et IO- sont v�ritablement des exemples de monades. Pour s�assurer que ce sont des monades au sens math�matiques, il faudrait travailler dur : prouver que ce sont des foncteurs, �laborer deux transformations naturelles  et  et prouver qu�elles sont naturelles, et enfin prouver les trois lois des monades.

Heureusement, il existe une fa�on plus simple d�y parvenir. Heinrich Kleisli, que nous avons d�j� rencontr�, a montr� que, s�il est possible de construire une cat�gorie comme celles de la section pr�c�dente, dont les fl�ches sont simplement des fonctions au domaine d�arriv�e modifi�, alors il est garanti que votre cat�gorie constitue �galement une monade. Ce qui est bien pratique, parce que, comme programmeurs, nous nous int�ressons nettement plus � nos fl�ches de Kleisli qu�au concept math�matique de monade. Rappel : ces fl�che de Kleisli sont exactement cette variation sur la notion des fonctions que nous avons utilis�e, bien avant de parler de th�orie des cat�gories ! Et Kleisli nous d�montre que, tant que la composition fonctionne comme attendu pour nos fl�ches de Kleisli (associativit� + identit�), il n�est plus besoin de prouver quoique ce soit d�autre pour �tre s�r de disposer d�une monade.

Cela reste int�ressant, � titre auxiliaire, d��tudier la relation entre les deux. Je ne donnerai pas tous les d�tails mais au moins la structure et laisserai au lecteur int�ress�, un peu familier avec la th�orie des cat�gories, le soin de faire la preuve des propri�t�s pertinentes. Nous utiliserons Err comme monade, pour choisir un des exemples �mais rien n�est sp�cifique � Err.

Nous commen�ons avec Err, qui est d�j� une application d�un ensemble vers un autre. Mais la d�finition traditionnelle demande �galement que ce soit un foncteur. Donc, si j�ai une fonction f de A � B, j�ai besoin de pouvoir construire une fonction Err(f) de Err(A) � Err(B). Je peux le faire de la fa�on suivante : dans la cat�gorie sous-jacente (la cat�gorie des ensembles, pas la cat�gorie de Kleisli), je prends une fonction d�identit� de Err(A) � Err(A) ; puis je prends l�identit� de Kleisli de B � Err(B). Je compose cette identit� de Kleisli avec f pour parvenir � une fonction de A vers Err(B). Je peux donc utiliser la composition de Kleisli entre Err(A) -> Err(A) et A -> Err(B) pour parvenir � Err(A) -> Err(B), c�est-�-dire Err(f).
Ensuite, j�ai besoin d�une transformation naturelle , provenant du foncteur identit� vers Err : rien de compiqu�, les composantes de  sont les identit�s de Kleisli.
Enfin, je dois trouver une transformation naturelle � de Err� � Err. Pour acc�der au composant de � aupr�s de A, je prends la fonctions d�identit� de la cat�gorie sous-jacente de Err(Err A) vers Err(Err A), puis de Err(A) vers Err(A) et je les combine avec la composition de Kleisli pour obtenir la fonction de Err(Err A) � Err A. Voil� le composant de �.

La construction dans le sens oppos� est nettement plus facile. En partant d�une monade Err avec  et �, la cat�gorie de Kleisli est construite de la fa�on suivante :
- les identit�s sont les composantes de 
- soient une fonction f de A � Err(B) et une fonction g de B � Err(C), je les compose par : � . Err(g) . f

Encore une fois, les d�tails des preuves sont laiss�es au lecteur. J�esp�re que ce bref d�tour aura �t� utile. Dor�navant, j�utiliserai le mot � monade �, mais entends � nouveau les monades via les cat�gories de Kleisli.

Rejoindre la r�volution monadique
R�capitulons une fois de plus :
- les programmeurs travaillent par compositions de choses qu�on appelle fonctions
- ces fonctions ne sont pas des fonctions au sens usuel, mais forment une cat�gorie
- en fait, ce sont bien des fonctions au sens usuel, mais uniquement si l�on en transforme les domaines d�arriv�e en quelque chose d��trange
- la cat�gorie qu�elles forment est appel�e une cat�gorie de Kleisli, c�est-�-dire en fait une autre fa�on de voir les monades
- ces monades d�crivent de fa�on satisfaisante les techniques utilis�es pour r�soudre des probl�mes pratiques

Les quatre exemples cit�s n��puisent pas le sujet. Ils sont repr�sentatifs de beaucoup, beaucoup d�autres id�es qui peuvent �tre d�crites dans le m�me cadre de pens�e. Il me para�t d�montr�, � ce stade, que celui qui cherche � �tudier et analyser les langages de programmation devrait �tre familier avec certaines id�es de la th�orie des cat�gories, et avec les monades en particulier.

Mais qu�en est-il de l�humble d�veloppeur, qui n�est pas en train de cr�er un nouveau langage, ne publie pas d�articles sur l�analyse des langages, mais veut simplement r�soudre les probl�mes qui se posent � lui tous les jours ? On est en droit de poser la question. Tant que les monades resteront un simple formalisme math�matique pour comprendre ce que les programmeurs entendent par fonction, des pr�occupations pratiques justifieront de ne pas chercher � les comprendre.

Il devient de plus en plus clair, cependant, que les monades ont entam� leur chemin vers les question pratiques de la programmation. Dans le pass�, les fl�ches de Kleisli, cette forme modifi�e des � fonctions �, �tait d�j� utilis�e pour construire les langages de programmation. Les fonctions en C utilisaient une certaine fl�che de Kleisli, et les fonctions en C++ une autre. Le standard du langage indiquait ce qui �tait possible et ce qui ne l��tait pas, et si nous voulions quelque chose de diff�rent, tant pis. Chaque d�cennie, peut-�tre, nous passions � un langage tout neuf et l�zardions aux rayons d�une nouvelle caract�ristique pour quelque temps.

Le pass� : gestion des erreurs
Prenons l�exemple de la monade Err, qui nous fournit des fonctions qui peuvent �chouer et faire part de leur �chec de fa�on structur�e : r�serve faite de quelques d�tails et extensions, il s�agit au fond de la gestion structur�e des exceptions. Les programmeurs ont travaill� sans disposer de gestion des exceptions dans leur langage pendant de nombreuses ann�es. Bien s�r, des langages comme le C sont Turing-complets et peuvent r�soudre n�importe quel probl�me de calcul, y compris la gestion des erreurs. Mais nous n�utilisons pas le concept de cat�gorie pour penser les calculs possibles : il sert � penser la composition. Sans gestion des erreurs au sein m�me de la notion de fonction adopt�e par des langages comme le C, la composition restait � la charge des programmeurs, � � la main �.

En cons�quence, une fonction C qui pouvait �chouer devait indiquer un �chec dans sa valeur de retour. Dans de nombreux cas, la convention �tait : � les valeurs de retour ne sont pas l� pour indiquer le r�sultat, mais le succ�s ou l��chec �. Les bonnes pratiques appelaient � faire suivre chaque appel de fonction ou presque d�instructions de v�rification du succ�s, et le code en devenait � peine lisible. C��tait le temps des algorigrammes et autre pseudo-code, parce qu�on n�esp�rait plus que le code soit lisible au premier regard ! En r�alit�, en fait, les programmeurs ne testaient le succ�s de leur fonction que lorsqu�ils croyaient l��chec possible, et de nombreuses erreurs n��taient pas d�tect�es. Les programmes n��taient souvent pas fiables et un nombre inconnu de milliards a �t� probablement d�pens� en d�veloppement suppl�mentaire et en correction de bugs.

Pourquoi cela ? C�est assez simple : parce que le C et les autres langages du temps reposaient sur un type de fl�che de Kleisli insuffisant ! Si leur fl�che de Kleisli avait inclus les fonctionnalit�s de la monade Err que nous avons d�finie, cela aurait pu �tre �vit�. Mais le concept de fonction support� par le C �tant fixe, la seule solution �tait de faire avec, et finalement de migrer vers un autre langage de programmation, avec r��criture de tout un tas de logiciels, et d�pense d�un nouveau nombre inconnu de milliards.

Le pr�sent : variables globales et contexte
Qu�en est-il de la monade Param et des autres �voqu�es ? Comme nous l�avons dit, il s�agit de d�finir des op�rations ayant acc�s � une information ext�rieure et � l��tat du reste du monde.

Dans le pass�, nous utilisions des variables globales, l��quivalent � peine plus moderne du stockage d�information � un endroit connu de la m�moire. Vite fait, mal fait, et les programmeurs d�il y a 30 ans savaient d�j� que ce n��tait pas une solution satisfaisante, impraticable pour des applications de plus grande taille. La programmation orient�e objet a permis d�att�nuer ce probl�me, en pla�ant les fonctions dans un � objet � qui leur sert de contexte et qui est transmis implicitement. Pour obtenir ce r�sultat, il a fallu changer de langage de programmation pour am�liorer, une fois de plus, la fl�che de Kleisli utilis�e. N�anmoins, la solution apport�e par les langages orient�s-objet reste imparfaite.

Le futur proche (/pr�sent) : puret�, effets, parall�lisme, non-d�terminisme, continuations et plus !
Je parle ici au futur, mais tout est d�j� possible, � condition de choisir le langage appropri� !

Un des d�fis adress�s � la communaut� des programmeurs est de trouver une fa�on efficace de g�rer le parall�lisme. Paradoxalement, tandis que les exemples pr�c�dents montraient des probl�mes caus�s par une fl�che de Kleisli pas assez puissante, cette fois-ci le probl�me est � l�oppos�. Les fonctions nues (ou pures) offrent un grand nombre d�opportunit� pour le parall�lisme. Lorsqu�elles sont ex�cut�es en parall�le, cela peut-�tre plus rapide, cela peut-�tre aussi plus lent si le parall�lisme est mal con�u, mais elles donneront de toute fa�on le m�me r�sultat. Mais si la fl�che de Kleisli incorpore les modifications destructrices, ce n�est plus le cas : le parall�lisme est risqu� et peu donner des r�sultats incorrects en raison de ce qu�on appelle les acc�s concurrents (� race conditions �).

Cependant, il est impossible de retirer les modifications destructrices de la fl�che de Kleisli d�un langage. Un programme qui n�a pas d�effets observables n�est pas utile, tout simplement. Ce qu�il faut pouvoir faire est de s�parer les parties du code qui effectuent des modifications destructrices de celles qui op�rent avec des fonctions pures. Donc, ce dont nous avons besoin, c�est d�un langage qui poss�de plusieurs sortes de fl�ches de Kleisli !

Il existe d�j� au moins un langage qui offre cette possibilit�. Les utilisateurs d�Haskell peuvent cr�er leurs propres monades et travailler dans la cat�gorie de Kleisli de leu choix. La langage dispose d�une syntaxe qui rend cette approche lisible et ais�e. Si une fonction peut �chouer, on la met dans Err ; si elle a besoin d�acc�der aux param�tres de l�application, dans Param ; de proc�der � des entr�es/sorties, dans IO. Les frameworks pour des applications web et d�autres projets similaires commencent par d�finir la monade appropri�e pour ce qu�ils ont � faire.

Une autre tendance de la communaut� des d�veloppeurs, en ce moment, est de cr�er davantage de mod�les de programmation sp�cifiques � un domaine. Le langage Erlang est devenu populaire parce qu�il fournit un mod�le de programmation avantageux pour le parall�lisme. Le framework .NET propose LINQ, qui offre un mod�le de programmation efficace pour traiter et requ�ter des collections de donn�es. Rails a popularis� les langages sp�cifiques au domaine de la programmation web. D�autres langages proposent des continuations pour construire des op�rations d�une mani�re plus flexible. Tous ces exemples montrent le besoin de travailler avec les fl�ches de Kleisli appropri�es � la t�che entreprise.

Au fond, si nous croyons qu�il existe une seule notion de � fonction � appropri�e pour l�ensemble des programmes informatiques, et qu�un langage existant la d�finit, nous pouvons rejeter, en tant que programmeurs, les id�es g�n�rales de monade et de fl�che de Kleisli comme une lubie de th�oriciens. Mais nous n�en prenons pas le chemin. La communaut� des programmeurs s�est engag�e r�solument dans une direction o� plusieurs d�finitions de la fonction coexistent, selon le contexte, la t�che � accomplir, ou m�me pour une application donn�e. C�est pourquoi il est important de disposer du langage, des outils, et des intuitions n�cessaires � la comparaison de ces abstractions. Tout cela, les monades nous les donnent.

Les abstractions construites sur les monades
Un langage qui permet de choisir ses monades offre encore d�autres avantages, en particulier un nouveau niveau d�abstraction. En Haskell, par exemple, il est possible d��crire du code applicable � diff�rentes monades. De fa�on surprenante, une part importante du code �crit pour une certaine monade fait sens pour d�autres monades �galement. Prenons par exemple le type Haskell suivant :

sequence : : Monad m => [m a] -> m [a]

Cela signifie, pour une monade M quelconque, que sequence convertit une liste de valeurs M(A) en M(List A), c�est-�-dire applique la monade � la liste elle-m�me. Prenons une minute pour en voir la signification pour nos quatre exemples. Pour Err, sequence prend une liste de r�sultats qui pourraient �tre un �chec, et si l�un d�entre eux est un �chec, toute la s�quence �choue. C�est simplement une fa�on pratique de v�rifier l��chec d�une liste compl�te d�op�rations. Pour Param, sequence prend un ensemble unique de pr�f�rences, le distribue � tous les �l�ments d�une liste et retourne une liste de r�sultats. Pour la monade P (ensemble des sous-ensembles), sequence prend une liste d�ensembles et retourne l�ensemble de toutes les fa�ons de choisir un �l�ment par ensemble. Enfin pour IO, il prend une liste de listes d�instruction, et retourne une liste unique de toutes les instructions � r�aliser dans l�ordre.
Une unique fonction, avec une seule impl�mentation, fait sens �et quelque chose d�utile- pour nos quatre exemples de monades !

Avec le choix des monades vient la capacit� de s�abstraire de ce choix et d��crire du code significatif pour n�importe laquelle des monades que l�on choisira.

Voyant toutes ces forces � l��uvre, je pr�dis que, d�ici dix ans, on attendra des d�veloppeurs logiciels qu�ils discutent des monades de la m�me fa�on qu�on attend d�eux aujourd�hui qu�ils discutent des design patterns ou des m�thodologies agiles.

Au-del� des monades : plus de programmation par les cat�gories
M�me si la plupart de ce qui a �t� dit concerne les monades, je ne voudrais pas laisser l�impression qu�elles sont la seule preuve de l�influence de la th�orie des cat�gories sur la programmation. Toutes les id�es ci-apr�s on fait leur chemin dans la pratique de la programmation, le plus souvent (jusqu�ici) dans la communaut� Haskell � cause de la flexibilit� du langage et de ses profondes racines acad�miques.

Les transformateurs de monade constituent une technique puissante pour combiner les effets de plusieurs monades et construire des mod�les de programmation vari�s et performants.
Les foncteurs et les foncteurs applicatifs sont moins puissants que les monades, mais d�une utilisation encore plus large.
D�autres genres de cat�gories, qui ne sont pas des cat�gories de Kleisli peuvent souvent �tre d�finies pour r�soudre des probl�mes sp�cifiques, dont les cat�gories de Freyd.

Je m�arr�te ici, mais uniquement pour vous encourager � rechercher vous-m�mes les abstractions vari�es de la th�orie des cat�gories que les programmeurs ont trouv�es utiles. Un bon point de d�part est la Typeclassopedia (sp�cifique � Haskell) de Brent Yorgey. Et ce n�est qu�une porte donnant sur les possibilit�s nombreuses d�application de la th�orie des cat�gories.

J�esp�re avoir �t� capable de convaincre que ces id�es n�ont pas �t� simplement invent�es mais sont l�extension naturelle de ce qu�ont fait les programmeurs pendant des d�cennies.

Une petite cuill�re de types (Haskell)

stendhal666 — Wed, 22 Apr 2015 09:37:04 GMT

Ce billet sera court et sans grande difficult�. Il servira de marche-pied ou d'aide-m�moire pour les billets suivants, qui pr�senteront un des aspects les plus excitants mais aussi les plus abstraits de la programmation en Haskell: l'apport de la th�orie des cat�gories au d�veloppement d'applications. Je tenterai ici de vous pr�senter, aussi clairement que possible, le syst�me de types de Haskell, � la fois souple et puissant.

Ce que vous savez d�j�
- Haskell poss�de un syst�me de type statique (la r�gularit� est v�rifi�e � partir du code, pas pendant l'ex�cution) et strict (aucune conversion automatique n'est accept�e).
- Le compilateur et l'interpr�teur sont capables, sauf ambigu�t� du programme, d'inf�rer les types utilis�s � partir d'�l�ments de contexte (ex: fonctions appel�es sur les arguments)
- la syntaxe basique d'une d�claration de type est:

nom :: Type

Par exemple:

> pi :: Double

Pour les fonctions, on a:

nomDeFonction :: arg1 -> arg2 -> ... -> argN -> returnType

Par exemple:

> integerSum :: [Integer] -> Integer

Ce que vous allez apprendre
Le syst�me de types Haskell est plus souple et plus puissant que cela. Il permet d'utiliser des types g�n�riques, plus ou moins semblables aux templates du C++, mais �galement d'ajouter des contraintes de type: pour reprendre l'exemple du C++, ces contraintes seraient l'�quivalent des "concepts" qu'il est envisag� d'ajouter dans une norme future du langage. Enfin, Haskell permet de cr�er de nouveaux types, des alias de types et enfin de les "recouvrir".

Les types g�n�riques
La fonction integerSum que nous avons d�clar�e est sympathique, mais si on lui donne une liste de Float, elle la refusera s�chement. Pourtant, l'algorithme pour additionner les membres d'une liste de Float ou de Double n'est pas diff�rent. Aussi existe-t-il la possibilit� de donner un type g�n�rique aux arguments d'une fonction:

> sum :: [a] -> a

NB: contrairement aux types concrets, les types g�n�riques commencent par une minuscule.

Les lecteurs attentifs se doutent que la fonction sum fait appel � un op�rateur (+), qui aurait donc comme signature:

> (+) :: a -> a -> a

Nous voil� dans une situation insatisfaisante: on voulait s'�viter d'�crire une fonction sum pour chaque type num�rique, et nous voil� avec un op�rateur d'addition qui accepte n'importe quel type: des connexions � des bases de donn�es, des arbres binaires... La seule contrainte est que chaque membre de l'addition, et le r�sultat, soient de m�me type (celui que 'a' repr�sente).

Les classes de types (typeclasses)
Haskell permet de cr�er des familles de types, qui peuvent �tre ensuite utilis�es pour placer des contraintes de types sur les arguments g�n�riques d'une fonction. Pour vous faire une id�e des familles pr�d�finies, en voil� la hi�rarchie en une image:

NB: vous pouvez retrouver cette image et des informations compl�mentaires ici.

La syntaxe pour cr�er une classe est la suivante:

class NomDeMaClasse where

fonction1 :: arg1 -> ... -> returnType
fonction1 =
fonction2 :: arg1 -> ... -> returnType
fonction2 =

...
Un exemple simple est la classe Eq:

class Eq a where

(==) :: a -> a -> Bool
x == y = if x /= y then False else True
(/=) :: a -> a -> Bool
x /= y = if x == y then False else True

Un type est une instance de la classe Eq si elle impl�mente au moins l'une des deux fonctions (remarquez en effet que chacune est d�finie par rapport � l'autre). Comme le nom de ces fonctions est d�j� pris (par la classe Eq), un m�canisme d'instanciation est n�cessaire -plus simplement, il faut d�clarer que notre type est une instance de cette classe. Par exemple, pour un type User:

instance Eq User where

(==) = sameId -- est vrai si les deux utilisateurs ont le m�me id

Lors de la d�claration d'une fonction, nous pouvons d�sormais exiger qu'un type abstrait soit l'instance d'une classe. La syntaxe est:

nomDeFonction :: constraint1 Class NomDe Type, constraint2 Class NomDe Type, ... => NomDeType -> NomDeType -> ...

Prenons l'exemple d'une fonction filtre, qui conserve les �l�ments d'une liste �gaux � son premier argument:

filter :: Eq a => a -> [a] -> [a]
filter _ [] = []
filter n (x : xs) = if x == n then x : (filter n xs) else filter n xs

Cr�er de nouveaux types
Cette possibilit� n'est r�ellement int�ressante que conjugu�e � la cr�ation de nouveaux types -et Haskell le permet. Si Haskell �tait d�pourvu d'un type Bool, on pourrait en cr�er un ainsi:

data Bool = True | False

- data est le mot cl� qui introduit la cr�ation d'un nouveau type
- Bool est le nom du nouveau type
- True et False sont les constructeurs d'instances de ce type
- et le symbole pipe ( | ) s�pare les constructeurs

Avec des constructeurs sans argument, on est tout de m�me un peu limit�. Pour reprendre notre type User, il pourrait �tre d�fini ainsi:

data User = User Integer String

- le nom du constructeur et du type peuvent �tre identiques

Un nouvel utilisateur peut �tre alors cr��:

> let myself = User 123 "stendhal666"

Mieux encore, un constructeur peut faire r�f�rence au type qu'il construit, afin de cr�er un type r�cursif. L'exemple canonique est celui de la liste:

data Liste a = Vide | Cons a (Liste a)

- Liste est un type abstrait, qui doit �tre param�tris� par un autre type (le type des �l�ments qu'elle contient)
- a est le nom du type (g�n�rique) qui param�trise le type Liste

On pourrait donc cr�er une de ces listes ainsi:

> Cons 'h' Vide

ou encore:

> Cons h (Cons a (Cons s (Cons k (Cons e (Cons l (Cons l Vide))))))

Conclusion:
Nous n'avons pas encore couvert tout le syst�me de type de Haskell, mais nous avons vu les aspects les plus int�ressants. Les alias ne pr�sentent pas de difficult� particuli�re: le mot-cl� type remplace le mot-cl� typedef du C/C++, essentiellement. La "couverture" de type est une notion un peu plus avanc�e dont les avantages n'apparaissent pas � ce stade: il me semblait donc inutile de surcharger cette cuill�re, qui est d�j� une bonne cuill�re � soupe...

Exercices:
- dans l'interpr�teur GHCI, la commande :t suivie d'une expression renvoie le type de cette expression. Regardez le type de quelques fonctions. En particulier, le type de l'op�rateur de composition (.) ou d'application $, ou encore le type de diff�rentes fonctions num�riques
- d�finir un type BinaryTree
- quels sont pour vous les avantages des diff�rents syst�mes de types?

Babel

stendhal666 — Fri, 17 Apr 2015 08:23:02 GMT

Toute la terre avait une seule langue et les m�mes mots. (...) Ils dirent encore: �Allons! Construisons-nous une ville et une tour dont le sommet touche le ciel et faisons-nous un nom afin de ne pas �tre dispers�s sur toute la surface de la terre.� L'Eternel descendit pour voir la ville et la tour que construisaient les hommes, et il dit: �Les voici qui forment un seul peuple et ont tous une m�me langue, et voil� ce qu'ils ont entrepris! (...) Allons! Descendons et l� brouillons leur langage afin qu'ils ne se comprennent plus mutuellement.� (...) Alors ils arr�t�rent de construire la ville. C'est pourquoi on l'appela Babel: parce que c'est l� que l'Eternel brouilla le langage de toute la terre et c'est de l� qu'il les dispersa sur toute la surface de la terre. Gen�se 11 1-9

Conna�tre plusieurs langages est-il souhaitable? Ce d�bat anim� trouve dans la Gen�se une r�ponse tranchante: l'unit� rend l'homme �gal � Dieu; la langue adamique, vestige du Paradis perdu, est ray�e de la surface de la terre pour ch�tier l'orgueil des hommes que la dispersion r�duit � l'impuissance. Il est vrai que les avantages d'un langage unique sont �vidents: compr�hensible par tous, compatible avec tout, p�renne, il rend les d�veloppeurs pour ainsi dire interchangeables. Plus de code mort, dont l'intelligibilit� a disparu avec le cr�ateur, plus d'erreurs ni de manque dans les biblioth�ques mille fois test�es! Tout le reste n'est que jouet de geek ou lubie de chercheur...

En comparaison, les avantages de la multiplicit� des langages sont obscurs. La fragmentation para�t bien un ch�timent, une mal�diction. Pourquoi alors s'y obstiner? Qu'est-ce qui pousse des programmeurs respectables � en explorer, voire � en cr�er toujours de nouveaux? Ce billet est une tentative de r�pondre � la question: j'y d�nonce le mythe du langage unique -une incompr�hension profonde de ce qu'est un langage informatique- pour en tirer quelques le�ons et une grande fiert� pour les programmeurs.

Pourquoi un langage, c'est d�j� plusieurs langages
La cr�ation de mots est l'activit� principale du d�veloppeur: cr�ation de nouveaux types (substantifs), de nouvelles fonctions (verbes), de nouvelles macros (constructions grammaticales)... D�fini par sa syntaxe et ses mots-cl�s, un langage informatique est plut�t un m�ta-langage, un outil pour cr�er d'autres langages aux vocabulaires et aux tournures vari�es. Cette caract�ristique des langages de programmation n'est peut-�tre pas apparente dans les programmes les plus triviaux; mais d�s que le code s'allonge et devient plus complexe, et d'autant plus s'il est une affaire d'�quipe, il devient �vident que chaque biblioth�que, chaque application cr�e son propre langage -un langage nouveau qui doit s'apprendre.

L'importance du langage naturel dans le code vient pr�cis�ment de ce ph�nom�ne. Que ce soit sous la forme de documentation, de commentaires, des noms de variable, il t�moigne du fait que le langage utilis� n'est que l'h�te d'un langage nouveau et que le conna�tre ne suffit pas � comprendre le code dont il fixe les r�gles. Si le paroxysme de ce processus de cr�ation est atteint dans les Domain Specific Languages, il n'y a entre eux et le reste des programmes qu'une diff�rence de degr�, pas de nature. Autrement dit, le langage unique n'est dans une certaine mesure qu'une fiction.

La complexit� croissante des programmes, le recours aux frameworks, � la cr�ation automatique de code -que ce soit par des interfaces XML ou dans le cadre de la programmation orient�e aspect, par exemple- ne fait que renforcer cette h�t�rog�n�it� entre le langage lui-m�me et les langages qu'il abrite; et, d'un certain point de vue, les standards de qualit�, les design patterns et les fonctionnalit�s des EDI se surajoutent encore au vocabulaire que doit ma�triser un d�veloppeur qui int�gre une �quipe.

Les objections du "pointy hairy boss"
Consid�rer qu'il n'existe pas de langage, mais toujours des langages, para�t n�anmoins tr�s intellectuel. L'objection vient naturellement: quand bien m�me chaque programme cr�erait un langage diff�rent, il reste plus facile � lire -et � �crire- pour quelqu'un qui est familier avec le langage h�te. Cet argument est pourtant imparfait: il y a le risque des "faux amis", qui trompent plus s�rement un connaisseur qu'un n�ophyte; et puis dans certains cas, des pans importants du langage h�te sont expr�s recouverts: ainsi le framework Qt, qui fait l'impasse sur la plus grande partie de la librairie standard du C++. Surtout, cet argument est r�versible: si conna�tre Java est cens� faciliter la compr�hension d'un programme �crit avec Hadoop, par exemple, on peut tout autant soutenir que conna�tre le C++ aide � comprendre Java (une affirmation du cr�ateur de Java lui-m�me), le C C++, et tout langage imp�ratif le C. R�ciproquement, conna�tre des langages fonctionnels ou distribu�s permet de mieux comprendre un programme Java �crit � grand renfort de map, de reduce et de lambdas pour un cluster de serveurs.

Il est vrai que ces arguments risquent de ne pas convaincre un responsable de SI, pr�occup� par des exigences imm�diatement op�rationnelles. A vrai dire, ce personnage qui hante les blogs de d�veloppeurs - le "pointy hairy boss", chef pointilleux et poilu, pour une raison qui m'�chappe - risque plut�t, en prenant conscience du risque de fragmentation, de r�duire encore les options � disposition des d�veloppeurs, sous pr�texte de productivit�. Eh bien, tant pis! si on ne me laisse pas le choix, d'accord, mais je refuse de me couper les c... avant qu'on me l'ait demand�!

Les le�ons � en tirer
Si la diversit� est inh�rente � la programmation, autant en tirer profit. C'est ce qu'ont fait avec succ�s des entreprises comme IBM, qui utilise Prolog dans son syst�me intelligent Watson, Facebook, Whatsapp ou Call of Duty qui ont choisi Erlang pour leurs applications de chat ou leurs serveurs de jeu. Un exemple plus ancien mais plus frappant encore d'une r�ussite fond�e sur l'utilisation d'un langage "� part" est celui que raconte Paul Graham dans son article Beating the averages: c'est gr�ce aux particularit�s de LISP qu'il s'est maintenu devant la concurrence lorsqu'il a cr�e ce qui est devenu Yahoo Store aujourd'hui.

Il ne faut bien s�r pas chercher la diversit� � tout prix. Mais il faut l'aimer pour elle-m�me, pour ce qu'elle donne d'ouverture d'esprit et d'adaptabilit�. La diversit� est, qui plus est, en partie apparente: pour celui qui conna�t les grandes familles de styles de programmation et de syst�mes de types, la plupart des langages, quelle que soit leur nouveaut� ou leur bizarrerie apparente, deviennent vite familiers. Ne nous restreignons pas � Java! Allons voir ces langages d�claratifs, fonctionnels, homoiconiques, � pile, � prototypes, objet, aspect, ces syst�mes de types statiques, dynamiques, stricts ou souples, � types d�pendants, g�n�riques!

De toute fa�on, l'expertise dans un langage ou un domaine particulier n'est possible qu'au prix d'une v�ritable culture g�n�rale. Prenez le C++: je suis frapp�, sur le forum, du nombre de personnes qui ne songent pas � utiliser les algorithmes de la librairie standard et les nouveaut�s du C++11, parce qu'elles reposent sur des principes fonctionnels, les fonctions d'ordre sup�rieur et la composition. Comme le fait remarquer le cr�ateur du langage, Bjarne Stroustrup, ce n'est pas un langage orient� objet mais un langage travers� par diff�rents paradigmes; sans culture g�n�rale, on n'en fera jamais qu'une utilisation limit�e. L'exemple du C++ contient en fait plus encore d'enseignements: la m�ta-programmation, qui en est une part d�sormais constitutive, a �t� d�velopp�e en grande partie gr�ce � la f�condation de la culture fonctionnelle; une bonne part du livre fondateur d'Andrei Alexandrescu, Modern C++ design, consacr�e aux typelists, est directement inspir�e de LISP.

Programmeurs de tous les pays, unissez-vous!
L'article � la base de la discussion sur le forum affirme -combien de fois l'ai-je entendu- que la vari�t� est un plaisir de geek, le caprice d'un enfant qui trouve un nouveau jouet sous le sapin. Que de m�pris! Cette vari�t� est le r�sultat de l'incorporation de r�flexions s�rieuses et interdisciplinaires. Le clivage entre les pr�occupations acad�miques et celles de la production existe certainement � un certain stade de maturit� d'un projet, mais l'histoire de l'informatique est celle de la f�condation de l'industrie par la recherche (la r�ciproque �tant �galement vraie). L�interdisciplinarit� cr�e, � la faveur des projets de recherche, des rapprochements inattendus: du calcul lambda � LISP, de LISP � l'intelligence artificielle, pour donner un exemple, dont le poids actuel est suffisant, je pense, pour r�cuser l'id�e d'un caprice: un nouveau langage n'est pas le dernier iPhone mais le v�hicule de concepts dont la port�e, en gestation encore, pourrait �tre d�terminante dans les ann�es � venir.

Je comprends que ce ne soient pas l� les pr�occupations d'un chef de SI. Mais il me semble que nous autres devons respecter notre art, et ne respecter les exigences du chef poilu qu'avec la pens�e de derri�re. Tirons fiert� de cette vari�t�!

Intelligence du morpion - la suite

stendhal666 — Mon, 13 Apr 2015 10:21:14 GMT

N.B : Comme le pr�c�dent, ce billet est largement inspir� de l�article de John Hugues : Why functional programming matters.

Dans le billet 19 bits, nous avions pos� les bases d'un jeu de morpion, en d�taillant l'impl�mentation du plateau de jeu, de l'arbre des positions utilis�e pour �tudier les coups possibles et de l'�valuation statique d'une position. Les deux fonctions cl�s -� ce stade, les d�tails de l'impl�mentation du plateau ne sont plus importants- �taient les suivantes:

buildGTree :: Int -> GameTree -- cr�e l'arbre de jeu en partant d'une position
prune :: Int -> GameTree -> GameTree -- taille l'arbre de jeu pour n'en conserver que n niveaux

L'algorithme minimax
Evaluer une position de fa�on statique est assez limit�: ne vous est-il jamais arriv�, concentr�s que vous �tiez sur une strat�gie pour mettre en �chec l'adversaire, d'oublier qu'il avait lui aussi une libert� de mouvement? Ou bien (je fais appel � des souvenirs de jeunesse) d'�tre obnubil�s par la rang�e de pi�ces rouges que vous constituiez au "Puissance 4" avant d'en �tre frustr�s par un impeccable rang de pi�ces jaunes?

L'algorithme minimax prend en compte les motivations de l'adversaire; il sait qu'il choisira le meilleur coup pour lui, pas pour vous. Si on assigne un score � une position, d'autant plus �lev� qu'il vous favorise et d'autant plus bas qu'il favorise l'adversaire, vous choisirez la position qui a le score le plus �lev�, et l'adversaire celle qui a le score le plus faible: regarder en avant dans la partie, c'est donc alterner maximum et minimum des positions possibles.

La premi�re �tape est donc d'attribuer de fa�on statique un score � chaque position. Nous avons d�j� la fonction d'�valuation, nomm�e � juste titre static. Il nous faut un moyen de l'appliquer � l'arbre de jeu:
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
mapTree :: (Int -> Int) -> GameTree -> GameTree
mapTree f (Node n []) = Node (f n) []  -- feuille
mapTree f (Node n ns) = Node (f n) (map (mapTree f) ns)  -- branche
Avec:

> mapTree static . buildGTree $ pos

On a donc l'arbre des �valuations statiques en partant d'une position

On peut alors d�finir maximise et minimise:
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
maximise :: GameTree -> Int		
maximise (Node n []) = n
maximise (Node _ ns) = maximum $ map minimise ns
 
minimise :: GameTree -> Int
minimise (Node n []) = n
minimise (Node _ ns) = minimum $ map maximise ns
Modularit� de la composition fonctionnelle et paresseuse
Pour r�capituler, nous pouvons d�sormais �valuer une position avec la fonction:

evaluate :: Int -> Int -- lance la co-r�cursion minimise / maximise
evaluate = maximise . mapTree static . prune 5 . buildGTree -- 5 est en quelque sorte le niveau de difficult� du jeu

Chaque composant est ind�pendant des autres: je peux remplacer presqu'� loisir, sans toucher � quoique ce soit d'autre, chacune des fonctions utilis�es. Je peux utiliser une nouvelle fonction de maximisation -c'est ce que nous ferons tout de suite avec l'optimisation alpha-beta- ou une nouvelle fonction d'�valuation statique, une nouvelle fonction d'�lagage de l'arbre, etc.

Qui plus est, et contrairement aux apparences, gr�ce � l'�valuation paresseuse, je ne traverse l'arbre qu'une seule fois! Je peux donc rajouter des �tapes d'optimisation ou de retraitement � ma convenance!

L'optimisation alpha-b�ta
Pour donner un exemple de cette modularit�, nous allons r��crire la fonction de maximisation en y incluant l'optimisation alpha-b�ta. Elle repose sur une observation simple, quoique contre-intuitive: pour d�terminer le minimum maximal (et r�ciproquement le maximum minimal), il n'est pas n�cessaire de parcourir toute la liste des minima (maxima). Cela permet d'�viter l'�valuation d'un certain nombre de coups qui ne se r�aliseront que si l'adversaire veut se tirer une balle dans la jambe...

Par exemple:

> maximum (minimum [2,1]) (minimum [0,5,-6,8,5,4,2,-1,-9,3,2,0,5,1,4,2])
--il n'est pas n�cessaire d'�valuer la partie en vert: de toute fa�on, z�ro comme minimum potentiel est d�j� inf�rieur au minimum de la premi�re liste

On peut capturer cette optimisation dans la fonction suivante:
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
alphaBetaMinimum :: [[Int]] -> [Int]
alphaBetaMinimum (nums : rest) = (potentialMin) : (omitIf  (<=) (potentialMin) rest)
where potentialMin = minimum nums
omitIf p a [] = []
omitIf p a (xs:xss)
	| any (p a) xs = omitIf p a xss -- d�s qu'un nombre est inf�rieur au minimum maximal connu, on passe
	| otherwise = (minimum xs) : (omitIf p (minimum xs) xss)
Il ne nous reste plus qu'� cr�er la fonction d'appel:
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
abMaximise :: GameTree -> Int
abMaximise = maximum . abMaximise' 
 
abMaximise' :: GameTree -> [Int]
abMaximise' (Node n []) = [n]
abMaximise' (Node _ subs) = alphaBetaMinimum . map abMinimise' $ subs
et � modifier evaluate:

evaluate = abMaximise . mapTree static . prune 8 . buildGTree -- on va plus loin dans l'arbre, et plus vite!

Conclusion:
Ce billet �tait le dixi�me de ce blog. J'esp�re avoir montr�, au fur et � mesure, l'int�r�t et peut-�tre la beaut� d'une programmation fonctionnelle modulaire et concise. Je continuerai dans les billets suivants � alterner pr�sentation de langages, de concepts et de cas pratiques. Je pense n�anmoins, dans le prochain billet, me livrer � une r�flexion plus g�n�rale sur la vari�t� des langages et le sens de cette vari�t� -en r�action, au moins partiellement, � la tr�s int�ressante discussion en cours sur le forum.

Exercices

- une des optimisations possibles de l'algorithme minimax est de ne retenir que les n meilleurs coups � disposition de l'adversaire pour poursuivre l'�valuation. Donnez un exemple d'impl�mentation.
- quelles modifications imposerait l'application de l'algorithme au jeu de dames? Quelles fonctionnalit�s pourrait offrir un langage pour les minimiser?

Pour faciliter l'exp�rimentation, le code source consolid� est disponible en pi�ce-jointe (extension en .txt car les fichiers haskell ne sont pas accept�s par le site !! / � transformer en .hs avant utilisation)morpions.txt

19 bits

stendhal666 — Tue, 07 Apr 2015 07:59:00 GMT

N.B : Ce billet est largement inspir� de l�article de John Hugues : Why functional programming matters.

Madame la Marquise m�a foutu les morpions�
Dans un pr�c�dent billet, je promettais une courte s�rie sur une A.I. simple et modulaire pour jeux de plateaux, sous la forme d�un hommage aux morpions. Cette A.I. met � profit les possibilit�s de composition de fonctions et d��valuation paresseuse introduites dans les pr�c�dents billets.

Un plateau de morpions
J�ai d�cid� de faire tenir mon plateau de jeu dans un entier. Aucune n�cessit� � cela, bien entendu, mais j�en profite pour montrer que l�optimisation n�est pas �trang�re aux langages � de haut niveau � qui peuvent tr�s bien travailler avec des bits.
Un plateau est donc d�compos� de la fa�on suivante :

Bits 0-8 : les jetons du joueur (on a qu�� dire les croix)
Bits 9-17 : les jetons de l�ordinateur (donc les ronds)
Bit 18 : 0 si c�est le tour du joueur, 1 pour l�ordinateur.

Un arbre de plateaux
Pour que l�A.I puisse faire des coups �clair�s, il faut qu�elle puisse se projeter dans le d�roulement de la partie. La fa�on classique de le lui permettre est de cr�er un � arbre de jeu �, dans lequel chaque position qu�il est possible d�atteindre � partir d�un plateau p est son enfant :

p
/ | \
e1 e2 e3

Mais mettons d�abord au point les d�tails d�une position.

Manipuler des bits
Haskell propose un syst�me de modules assez complet. Pour en effleurer la surface, je pr�cise seulement que vous devrez ajouter � import Data.Bits � au d�but de votre programme, ou, dans l�interpr�teur, indiquer � :module Data.Bits �, pour utiliser certaines des fonctions employ�es dans ces bouts de code.

Comme la position d�un joueur est encod�e sur 9 bits, il nous faut un masque pour cacher le reste :

mask9 :: Int --les valeurs enti�res sont par d�faut des Integer (infinis), pr�ciser donc le type Int (32/64 bits) pour une optimisation sans effort
mask9 = 2^9-1 -- #111111111b ( ! ce n�est pas un litt�ral Haskell ; pas h�las de repr�sentation binaire native)

turnBit :: Int --pour donner un nom au bit qui d�termine de qui c�est le tour.
turnBit = 18

allMoves :: [Int] --tous les mouvements possibles : une compr�hension de liste qui sera m�mo�s�e apr�s sa premi�re utilisation
allMoves = [2^x | x <- [0..8]]

Bit I/O
Pour simplifier l��criture des positions, nous �crivons deux petites fonctions pour faire nos op�rations de lecture et d��criture dans les positions encod�es dans un entier : une pour lire (decomp), une pour �crire (rebuild).

rebuild :: Int -> Int -> Int -> Int --trois entiers pour en faire un seul : � qui de jouer, la position du joueur, la position de l�ordinateur
rebuild t c p = p .|. (shiftL c 9) .|. (shiftL t turnBit) -- shiftL x n : d�place n fois � gauche les bits de x / .|. est le � ou � binaire

NB : (x, y, z) est un � tuple � � trois �l�ments : contrairement aux listes, ils peuvent �tre h�t�rog�nes.

decomp :: Int -> (Int, Int, Int) --l�op�ration inverse
decomp p = (if testBit p 18 then 1 else 0, (shiftR p 9) .&. mask9, p .&. mask9)

L��l�gance fonctionnelle
Gr�ce au pattern matching et � la composition de fonctions, nous pouvons �crire une fonction dense et courte (je vous encourage � lire les billets pr�c�dents si certains �l�ments vous manquent pour la compr�hension) pour g�n�rer les possibles positions suivantes :

nextPositions :: (Int, Int, Int) -> [Int]
nextPositions (1, c, p) = map (\x -> rebuild 0 x p) . map (.|. c) . filter (\m -> (m .&. (p .|. c)) == 0) $ allMoves
nextPositions (0, c, p) = map (rebuild 1 c) . map (.|. p) . filter (\m -> (m .&. (p .|. c)) == 0) $ allMoves

nextPositions utilise le pattern matching pour r�cup�rer de fa�on �l�gante les informations contenues dans le tuple g�n�r� par decomp :

nextPositions . decomp $ 0 --g�n�re les positions possibles apr�s la position initiale (tout � 0, c�est le tour du joueur)

L�infini est un outil bien pratique
Il nous faut tout de m�me une structure h�te, l� arbre, pour placer les positions g�n�r�es. Haskell permet de d�finir de nouveaux types gr�ce au mot-cl� data. La syntaxe (dans sa forme la plus simple �il faudra vraiment que je revienne sur le syst�me de type de Haskell dans un autre billet) est :

data NomDeType = constructeur arg1 arg2 � argN

Dans notre cas, nous l�avons dit, chaque n�ud contient une position et ses enfants (qui sont aussi des arbres de jeux ; c�est une structure r�cursive, encore !) :

data GameTree = Node Int [GameTree]

Il nous suffit donc, pour g�n�rer l�arbre de jeux, d�appliquer le constructeur de GameTrees aux positions suivantes de celle dont on part :

buildGTree :: Int -> GameTree
buildGTree p = Node p (map buildGTree (nextPositions . decomp $ p))

Si j��cris :

buildGTree 0

j�obtiens l�arbre de jeu entier des morpions �mais je pourrais l�utiliser pour un jeu o� les possibilit�s sont infinies, gr�ce � l��valuation paresseuse ! N�en sera �valu� que ce je demanderai�

Une fonction pour dompter l�infini
Il y aurait quand m�me un certain danger � lancer l��valuation sur l�arbre infini. Apr�s tout, m�me pour un jeu de morpions, il y a 9 ! = 362880 parties possibles. Alors imaginez qu�on r�utilise notre squelette pour un jeu d��chec !

Il nous faut donc une fonction �quivalente � take (cf billet pr�c�dent) qui fonctionne pour les arbres :

prune :: Int -> GameTree -> GameTree
prune 0 (Node t _) = Node t []
prune n (Node t rest) = Node t (map (prune (n-1)) rest)

prune n gt --donne les n premiers niveaux de l�arbre

Pour �tre tranquilles avant le prochain billet
Dans le prochain billet, nous mettrons en place l�A.I. � proprement parler, sous la forme de l�algorithme minimax, avec le raffinement alpha-b�ta. Pour pouvoir nous concentrer l�-dessus, terminons ce billet par l��criture d�une fonction d��valuation statique : elle d�termine le score sans regarder les positions suivantes. Elle est simple : elle renvoie 1 si l�ordinateur gagne, -1 si c�est le joueur et 0 sinon.

Pour d�terminer si les positions sont gagnantes, un peu d�infrastructure est n�cessaire :

makeMask :: [Int] -> Int --construit un masque � partir de la liste des bits allum�s
makeMask = foldr ((+) . (2^)) 0 --encore un pliage de liste ! ((+) . (2^)) < = > \x y -> 2^x + y

-- la liste des bits allum�s dans les positions gagnantes
winners� = [[0,1,2], [3,4,5], [6,7,8], -- lignes

[0,3,6], [1,4,7], [2,5,8], -- colonnes
[0,4,8], [2,4,6]] -- diagonales

winners = [makeMask onBits | onBits <- winners�] --on met le tout dans une structure pour que le calcul soit m�mo�s�

Il suffit ensuite de comparer avec la position des deux joueurs :

NB : les pipes ( | ) dans la fonctions sont des � gardes �. Elles correspondent � un switch dans un autre langage : si la condition qui les suit est vraie, la fonction retourne l�expression qui suit cette condition.
La syntaxe est :
NomFonction args

| condition = expression
�
| otherwise = expression --otherwise < = > par d�faut

static :: (Int, Int, Int) -> Int --� employer avec decomp
static (_, p, c)

| any (\x -> x == x .&. p) winners = -1 -- any f lst est vraie si f est vraie pour au moins un �l�ment de lst / .&. = binary and
| any (\x -> x == x .&. c) winners = 1
| otherwise = 0

Et voil� ! en quelques lignes de code (dont une bonne part aurait pu / d� �tre g�n�ralis�e � un arbre est une structure bien pratique et tr�s commune, apr�s tout), nous avons d�j� fait l�essentiel du travail. Dans le prochain billet, l�A.I proprement dite et quelques r�flexions sur la modularit� particuli�re des programmes fonctionnels !

Exercices :

- repr�sentez le plateau d�un jeu de dames
- quelle fonction d��valuation statique pourrait �tre utilis�e pour le jeu de dames ?
- lisez l�article dont le billet est inspir�, qui donne d�autres exemples int�ressants d�impl�mentations modulaires pour diff�rents algorithmes
- pour les bons en maths : si une position gagnante ne conduit � la g�n�ration d�aucune position nouvelle, de combien de positions l�arbre de jeu complet sera-t-il constitu� ?

Paresse

stendhal666 — Wed, 01 Apr 2015 12:35:10 GMT

Les joies de la procrastination
Je voudrais introduire ici l��valuation paresseuse (� lazy evaluation �) caract�ristique de certains langages fonctionnels, au premier rang desquels Haskell, qui faisait l�objet des deux pr�c�dents billets (1 2). Elle consiste, en deux mots, � reporter l��valuation d�une valeur au moment o� elle est devenue n�cessaire.

L��valuation paresseuse n�est pas l�apanage des langages fonctionnels �bon nombre d�entre eux reposent d�ailleurs au contraire sur le principe de l��valuation stricte, ou imm�diate. Inversement, elle peut appara�tre dans des langages imp�ratifs : une biblioth�que de traitement des matrices, �crite en C++, en fait d�ailleurs usage, comme du � polymorphisme statique �, pour accro�tre ses performances. Cependant, l��valuation paresseuse cr�e plus de probl�mes qu�elle n�en r�sout lorsque le programme est constitu� d�une succession d��tats : l��tat du programme peut avoir chang� entre la d�finition de la valeur et son utilisation. Les principes fonctionnels garantissent en revanche que ce ne sera pas le cas.

Les b�ufs et la charrue
L��valuation paresseuse est une g�n�ralisation du bon sens. Bon sens caract�ristique du programmeur, qui n��crira jamais :
Code C : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
pFile = fopen(file) ;
bool ok = grosseFonctionDeLaMort() ; // je vais appeler cette fonction pour rien, peut-être…
if ( pFile && ok) { …
mais :
Code C : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
pFile = fopen(file) ;
if ( pFile && grosseFonctionDeLaMort() ) { … // si pFile n’est pas ouvert, grosseFonction ne sera pas évaluée
Dans un programme paresseux, les appels de fonction et les valeurs non-triviales (ce n�est donc pas le cas des litt�raux, par exemple) sont initialement � l��tat de � thunk �, c�est-�-dire en attente d��valuation. Les thunks ne sont �valu�s qu�au moment o� c�est n�cessaire.

What�s the point ?
Evidemment, la plupart des valeurs d�finies seront utilis�es, et la plupart des thunks �valu�s. Prenons l�exemple d�une fonction de tri : il est �vident que toutes les valeurs de la liste tri�e seront �valu�es � un moment ou � un autre. Le tri est par nature une op�ration stricte.

Inversement, prenons l�exemple d�une fonction qui renverrait les �l�ments d�indice pair dans une liste :
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
evens []  = []
evens [x] = [x]
evens (x:_:xs) = x : evens xs     --les éléments impairs ne seront pas évalués
Vers l�infini et au-del�
Une cons�quence particuli�rement int�ressante de l��valuation paresseuse est la possibilit� de travailler sur des structures infinies �les arbres et les listes, par exemple.

La liste des entiers � partir de 1 peut �tre d�finie tout simplement :

posIntegers = [1..] -- les entiers de 1 � 9 pourraient �tre d�sign�s par [1..9]

Au-del� de ce sucre syntaxique, voici une fonction inifinie :

fib m n = m : (fib n (m+n)) --la suite de Fibonacci

Comment utiliser ces listes ou ces fonctions infinies ? Elles peuvent servir en argument d�une fonction qui d�finit la portion qu�elle veut utiliser. La fonction la plus simple est take :

take 0 _ = []
take n (x : xs) = x : (take (n-1) xs)

> take 5 $ fib 1 1
[1,1,2,3,5]

M�moire de l�infini
Autant une valeur, une fois �valu�e, pourra �tre r�utilis�e sans nouvelle �valuation (le thunk a �t� remplac� par une valeur � l�adresse point�e par le nom de la variable), autant chaque appel de fonction aboutira � la cr�ation d�un nouveau thunk. L�application d�une technique de � m�mo�sation � est possible, mais � la charge du programmeur.

Cependant, les structures de donn�es nomm�es b�n�ficient automatiquement de cette technique. Les �l�ments �valu�s d�une liste infinie, d�finie par une fonction par exemple, resteront en m�moire.

List comprehension
Les � list comprehensions � dont la traduction litt�rale, � compr�hension de liste �, est un peu ambigu�, mettent l�accent sur cette possibilit� de m�mo�sation. Voici quelques exemples de leur syntaxe :

-- [ fonction | arg <- source ]
puissancesDe2 = [2^x | x <- [1..]]

-- [fonction | arg1 <- source1 , arg2 <- source2]
-- lorsqu�il y a plusieurs sources, fonction est appliqu�e � leur produit cart�sien
ProdCart m n = [ [x, y] | x <- [1..m], y <- [1..n]]

> ProdCart 4 4
[[1,1],[1,2],[1,3],[1,4],[2,1],[2,2],[2,3],[2,4],[3,1],[3,2],[3,3],[3,4],[4,1],[4,2],[4,3],[4,4]]

Une petite torsion de cerveau pour finir
L��valuation paresseuse permet de cr�er des compr�hensions de listes infinies par r�cursion. Je vous laisse m�diter cet exemple :

fib = 1:1:[x | x <- zipWith (+) fib (tail fib)] -- zipWith f a b cr�e une liste r�sultant de l�application de f � chaque �l�ment de a et de b

Exercices :

- r�digez une compr�hension de liste d�finie comme l�ensemble des nombres premiers
- voyez-vous les avantages pratiques � travailler avec des structures inifinies ? expliquez pourquoi
- pourriez-vous impl�menter l��valuation paresseuse dans votre langage favori ? � quel prix ? qu�est-ce que cela dit de l��quivalence de Turing ?

Origami

stendhal666 — Tue, 31 Mar 2015 10:06:11 GMT

L�imagination au pouvoir
L�Origami, art du pliage, permet de transformer une simple feuille en une grue, un canard ou un brontosaure �art po�tique, donc, qui fait �merger de la virginit� d�une page un monstre depuis longtemps disparu ou le vol d�un oiseau. Peut-�tre que notre activit� �� nous autres programmeurs- n�a pas pour le grand public l�attrait oriental de cette discipline �pur�e et pourtant ! ne consiste-t-elle pas � faire �merger du chaos d�interminables s�quences de bits des structures vivantes et disciplin�es ?

L�art du pliage
C�est dans cet �tat d�esprit que je voudrais aujourd�hui illustrer l�art du pliage� des listes. Nous r�p�terons les gestes constitutifs de cet art comme autant de katas pour en percevoir l�extr�me versatilit�.

Il existe essentiellement deux formes de pliage : de gauche � droite, et de droite � gauche. De gauche � droite, on pose d�abord un pan du tissu sur la table, puis on ram�ne le tissu, pli par pli. De droite � gauche, on tient le tissu � la main et on l�attire vers soi, pour ne le d�poser qu�� la fin sur la table. Pour plier une liste, �galement, on suit un ordre ou l�autre : il nous faut une fonction qui d�crive le pli, une valeur initiale qui tient lieu de table et une liste, enfin, notre tissu. En voici la transcription en code

N.B : pour les rudiments de Haskell n�cessaires � la lecture de ce billet, voir le pr�c�dent.
Code Haskell : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
-- foldl : fold en anglais, plier en français ; l pour left : de gauche à droite
foldl _ i [] = i      --il n’y a plus de morceau à plier, on donne la liste pliée
foldl f i (x:xs) = foldl f (f i x) xs    --on replie sur la valeur initiale le prochain pan de la liste
 
-- foldr : fold right, de droite à gauche
foldr _ i [] = i    -- arrivés au bout de la liste, nous la posons sur la table
foldr f i (x:xs) = f x (foldr f i xs)     --nous plions le premier morceau de la liste sur le reste de la liste à plier
Quelques figures simples
Regardons un peu ce que l�on peut faire avec ces deux gestes simples et des fonctions primitives :

copy = foldr ( : ) [] --le constructeur de liste, qui est un op�rateur, est plac� entre parenth�se pour �tre utilis� comme une fonction
length = foldr (\x y -> 1+y) 0 --longueur de la liste
remove elem = foldr (\x y -> if x == elem then y else x:y) [] --retirer un �l�ment de la liste
sum = foldr (+) 0 --somme
product = foldr (*) 1 --produit
append a b = foldr ( : ) b a --concat�ner deux listes
map f = foldr (( : ) . f) [] --appliquer une fonction � une liste

La direction du pli ne compte pas toujours, mais souvent: Prenez par exemple ce joli bout de code :

N.B : flip intervertit l�ordre des arguments d�une fonction : flip f = \x y -> f y x

reverse = foldl (flip ( : )) [] --inverse l�ordre de la liste

Une figure pour le poker
Je vous avais promis une formulation plus �l�gante de split-if, utilis�e pour analyser les mains au poker (fonction d�velopp�e et utilis�e lors des trois pr�c�dents billets), la voici, d�un geste de Samoura� :
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
--@ permet de nommer la structure d�construite par pattern matching
splitIf' p xs = foldr (ft p) [[]] xs
where ft _ x [[]] = [[x]] ;
ft p x n@((y:ys):zs) = if p x y then [x] : n else (x:y:ys) : zs
En voici une de disambiguate :
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
disambiguate' a b = foldr (\x y -> if x == EQ then y else x) EQ $ zipWith compare a b       
--les recherches sur compare et zipWith sont laiss�es au lecteur
Plier son cerveau
Enfin je propose, � ceux qui n�auraient dans la journ�e que la stimulation intellectuelle de faire des boucles,
Code : S�lectionner tout - Visualiser dans une fen�tre � part
for (int i = 0 ; i < MAX_VAL ; ++i)  // si j�avais gagn� un euro � chaque fois�
un petit bout de code qui leur tordra convenablement le cerveau :
Code : S�lectionner tout - Visualiser dans une fen�tre � part
foldl f a bs =   foldr (\b g x -> g (f x b)) id bs a
Pour ceux qui doutent encore�
de l�int�r�t de tout cela, j�annonce une s�rie de billets prochains sur la mise en place d�une IA simple et modulaire pour des jeux de plateau mettant � profit les katas du jour. Nous rendrons ainsi hommage aux morpions !
Comme il se peut que j�aie quelques notions importantes � pr�senter d�abord, laissez-moi tout de m�me un ou deux billets avant de lancer la s�rie.

Exercices :
- r�fl�chir aux repr�sentations d�un plateau de morpions
- faites une recherche sur l�algorithme minimax
- �tes-vous plut�t strict ou paresseux ? si vous �tes plut�t paresseux, je montrerai dans le prochain billet tous les b�n�fices de ce trait de caract�re�

Vanilla	do-notation
sat =	sat = do
item >>= \c ->	c <- item
if f c then�	if f c then�