Tri | Dr. Goulu

Comment bien brasser les cartes

Sat, 19 Jan 2013 00:00:00 +0000

Les amateurs de jeux de cartes savent qu’il faut accorder beaucoup d’attention au brassage des cartes pour éviter la triche, mais qu’en est-il par exemple dans les jeux de poker en ligne ?

Les informaticiens se sont beaucoup , mais relativement peu sur les problèmes de brassage, moins fréquents et apparemment plus simples. Mais comme disait : “il faut se méfier des appâts rances” ©…

Examinons pour commencer un algorithme tout bête que j’avoue avoir utilisé plusieurs fois : on échange la première carte (ou donnée) avec une autre choisie au hasard parmi les N cartes*, puis on fait de même pour la 2ème carte, la 3ème et ainsi de suite jusqu’à la N-ième. Cette méthode semble réunir toutes les caractéristiques d’un bon algorithme : simplicité, rapidité, et efficacité.

(Si vous avez un vrai browser, . C’est ma première oeuvre faite avec , fortement inspirée de , et que j’essaie désespérément d’inclure directement dans cet article…)

Et pourtant, un tel brassage s’avère “biaisé” : toutes les possibles n’ont pas la même probabilité d’être produites. Déjà en ne brassant que N=3 cartes par cette méthode, 3 des 6 permutations possibles sont nettement moins probables que les 3 autres .

biais naïve swap (i ↦ random)

Avec N=60 cartes, ce biais est bien visible sur la figure ci-contre, produite par une autre en ligne . Elle effectue 10'000 mélanges avec le même algo, compte dans une matrice le nombre de fois ou la i-ième carte se retrouve à la j-ième position après le brassage, et représente les positifs en vert et les négatifs en rouge.

La variante “swap (random ↦ random)” dans laquelle on échange N fois 2 cartes choisies au hasard n’est pas meilleure : elle présente un biais positif sur la diagonale (i=j) qui s’atténue si on effectue 2N échanges, et disparaît presque pour 3N échanges.

Signifierait-ce qu’il faut plus de N opérations pour obtenir un “bon” brassage de N cartes ? On pourrait le penser car il existe un algorithme tout simple sans biais : extraire successivement des cartes prises au hasard dans le tas pour en constituer un deuxième, mais il nécessite N.log(N) opérations***, voire N² s’il est mal programmé . Or N.log(N) est la complexité des algorithmes de tri, donc on pourrait avoir l’idée aussi surprenante que séduisante de se faire un brassage en utilisant auquel on passe une fonction aléatoire comme critère de tri.

C’est tellement beau que j’exhibe même ici le petit bout de code Javascript qui fait ça:

\[source language="javascript"\]

function shuffle(array) { array.sort(function() {return Math.random() - .5}); }

\[/source\]

biais sort (random comparator)

random() renvoie un nombre aléatoire entre 0 et 1, donc Math.random() - .5 tire à pile ou face si une carte est “plus grande” que l’autre lors du tri, ce qui est supposé mélanger au lieu de trier.

Cette méthode produit la matrice de biais ci-contre, dont la non-trivialité me laisse pantois.

Par contre, la variante dans laquelle on commence par générer un vecteur de nombres aléatoires, puis on “dé-trie” les données en utilisant ces nombres aléatoires pour les comparaisons donne un résultat non biaisé. (voir “sort (random order)” dans )

Et une fois qu’on est tout content d’avoir trouvé un algorithme de brassage non biaisé de complexité N.log(N), on découvre celui de datant de 1938, non biaisé, assez simple :

\[source language="javascript"\]

function shuffle(array) { var j = array.length, t, i; while (j) { i = Math.floor(Math.random() * j–); t = array

\[j\]

; array

\[j\]

= array

\[i\]

; array

\[i\]

= t; } }

\[/source\]

Les 3 dernières lignes échangent les cartes en i-ième et en j-ième position tout comme dans notre premier algorithme naïf, mais ici on ne choisit la carte à échanger que parmi celles qui n’ont pas encore été traitées. Et pour des raisons de simplicité du code, on mélange le tableau “depuis la fin”.

Et le plus beau est que sa est proportionnelle à N, ce qui est in exemple de plus de l’universalité du principe de Murphy de la thermodynamique de la tartine beurrée qui dit qu’il est toujours plus facile de générer du désordre que de l’ordre.

D’autre part, si vous devez brasser beaucoup de données de manière irréversible, je ne sais pas moi, pour une application de vote par internet par exemple, souvenez-vous de Fisher-Yates. Et utilisez un , car un peut non seulement souffrir de biais, mais surtout être reproductible à partir de la “graine” et permettre ainsi d’inverser le brassage.

Bon, je voulais encore modéliser différentes techniques de brassage de vraies cartes en JavaScript pour déterminer combien d’opérations sont nécessaires pour obtenir un mélange sans biais, mais je préfère laisser ça en exercice pour ChipRaptor et d’autres.

Notes:

Gag © Pierre-Alain de

* et non N-1, car il faut garder une chance sur N que la carte soit “échangée avec elle même” et reste à sa place dans le tas.

** félicitations au premier lecteur qui calculera les probabilités respectives de ces permutations et expliquera ainsi le biais…

*** parce qu’on doit alors forcément parcourir des

Références:

, “ ”, 14 janvier 2012
Mike Bostock, “ ”, 21 janvier 2012
Jeff Atwood “ ”, 2007, Coding Horror

Le "Sleep sort"

Sun, 19 Jun 2011 00:00:00 +0000

Tout a commencé* par un : un anonyme propose un algorithme de tri en 2 lignes de code :

function f() {sleep "$1" echo "$1"} while [ -n "$1" ] do f "$1" & shift done wait

Lorsqu’il est appelé avec une liste de N nombres comme dans ./sleepsort.bash 5 3 6 3 6 3 1 4 7 , ce code lance un processus pour chacun des nombres n. Chaque processus effectue la fonction f, qui utilise la fonction pour attendre n secondes avant d’afficher le nombre n. Dans l’exemple, le 7ème processus n’attendra qu’une seconde avant d’afficher “1”, le 4ème et le 6ème attendront 3 secondes avant d’afficher “3” dans un ordre qui n’a aucune importance et ainsi de suite jusqu’au dernier processus qui affichera “7” après 7 secondes. L’utilisateur verra ainsi s’afficher progressivement les N nombres triés dans l’ordre croissant.

Depuis ce message on voit des implémentations de “Sleep sort” fleurir dans programmation en utilisant , et des , anglophones surtout pour l’instant.

Prétextant que ce programme mettrait plus de 11 jours à trier les deux nombres 1000000 et 673, certains considèrent le “sleep sort” comme un bon gag, ce qu’il est certainement à l’origine. Pour ma part j’ai de la . Voici pourquoi.

D’abord, ce code est simple et fait l’éloge d’une grande qualité du programmeur : la paresse. Faire quelque chose d’utile simplement en attendant, quoi de plus beau ? A ce titre il mérite amplement sa place à côté du dont en français, du ou des et sans intérêt, mais qui ont leur page Wikipédia.

Photo par Eben Regis sur flickr

Plus sérieusement, “Sleep sort” exploite de manière active l’écoulement du temps au lieu de le subir, ce qui est déjà intéressant en soi, mais pose également des questions intéressantes sur la .

Car le “génie” de cet algorithme, s’il vous avait échappé, est qu’il prend en apparence un temps proportionnel à max(n), le plus grand des nombres à trier, pour s’exécuter, plus un temps proportionnel à N pour créer les processus. Or les existants prennent un temps proportionnel à N.log(N). Il pourrait donc exister des cas où le “sleep sort” serait plus rapide. Mais est-ce vraiment le cas ?

Traitons d’abord de la partie la plus perceptible du temps d’exécution, l’attente de max(n) secondes. Sur les machines actuelles, , et on pourrait probablement passer aux microsecondes. En fait il faut simplement garantir que deux processus associés à deux nombres x et x+1 se réveillent dans le bon ordre et aient le temps de produire leur sortie sans perturber le réveil des processus suivants. Déjà ceci soulève plein de problèmes intéressants au niveau des systèmes d’exploitation, de l’accès aux ressources critiques etc. Mais quelles que soient les solutions techniques, il reste qu’on ne sait pas bien exprimer théoriquement la complexité d’un tel algorithme : en principe, une durée d’exécution proportionnelle à l’une des données conduit à une complexité O(1) supposée largement inférieure à O(N), ce qui n’est pas le cas en pratique ici.

Ensuite la partie “proportionnelle à N” dans laquelle on crée les N processus est elle vraiment O(N) ? En principe oui, mais il existe une partie invisible : la gestion interne de la fonction système “sleep”. Dans tous les systèmes d’exploitation que je connais (au moins deux…), “sleep” provoque l’insertion du processus dans une liste de tous les processus suspendus en attente de l’échéance d’un certain temps. Et pour éviter de parcourir toute la liste à chaque interruption du timer pour trouver quels processus doivent être réveillés, on la maintient triée dans l’ordre des réveils programmés. “Triée” ? Et oui… : à chaque instruction “sleep”, rencontrée le processus est inséré au bon endroit. “Inséré” ? Et re-oui… : l’exécution des N “sleep” revient à un “ ”, d’une complexité O(N²) rédhibitoire.

“Sleep sort” n’est donc pas un tri linéaire, du moins sur un ordinateur ayant beaucoup moins de N processeurs. Mais il soulève plein de questions intéressantes sur les algorithmes, les systèmes d’exploitation, l’architecture des ordinateurs et la psychologie des programmeurs. !

Note* : en fait l’idée est plus ancienne comme le montre ce post “ ” datant de 2006

Tri réversible ?

Sat, 30 Jan 2010 00:00:00 +0000

animation de l’algorithme Quick Sort

En informatique, le tri est une opération incontournable car il est beaucoup plus rapide de rechercher une information dans une liste triée que dans un fouillis. C’est pourquoi j’ai longtemps cru qu’une liste triée contenait plus d’information qu’une liste non triée, car je voyais le tri comme un pré-traitement permettant d’accélérer les opérations suivantes, donc un “plus” par rapport à une situation “moins” performante.

Pris d’un doute il y a quelques années, j’avais posé la question sur un forum consacré à l’informatique théorique :

“est-ce qu’une liste triée contient vraiment plus d’information qu’une liste non triée ?”

Un érudit professeur m’avait répondu simplement ceci :

“ce contient d’ est- information liste liste? non plus qu’ qu’ triée triée une une vraiment”.

J’ai mis un moment à comprendre la profondeur de cette réponse : ma question, une fois les mots triés par ordre alphabétique, était devenue incompréhensible, et contenait donc moins d’information que la phrase originale ! Depuis je sais que .

a reposé la question sous un angle intéressant : est-il possible de programmer un algorithme de tri “réversible”, permettant de remettre une liste triée dans son état initial ? Évidemment oui : il suffit de stocker en plus l’information perdue lors du tri, le plus simple étant de mémoriser l’état initial de la liste par exemple en ajoutant à chaque élément trié son numéro d’ordre :

“ce2 contient7 d’10 est-1 information11 liste5 liste14 non15 plus9 qu'3 qu'12 triée6 triée?16 une4 une13 vraiment8 ”.

Pour une liste contenant n éléments, on a besoin de log(n) bits* pour stocker chaque numéro, donc de n.log(n) bits au total.

Peut-on faire mieux? On pourrait se dire que beaucoup d’ comme permutent des éléments après les avoir comparés, et qu’il suffirait donc de stocker le résultat des comparaisons effectuées, soit un bit par test, pour pouvoir ensuite “défaire le tri” en parcourant la liste des bits à l’envers. Combien faut-ils de bits ? ben … au moins n.log(n) aussi puisque c’est justement le nombre de comparaisons qui détermine la “complexité” des algorithmes de tri, et que les bons algorithmes ont une complexité de n.log(n).

Rien ne sert de se casser la tête sur “algorithme de tri réversible”, il ne peut pas être plus efficace que de simplement stocker l’ordre initial des données. Etonnant non ?

Le problème, c’est que la donnée du concours spécifie qu’on n’a le droit de stocker que 50% d’information supplémentaire par rapport à la taille des données : si on trie 4K octets, on n’a droit qu’à 2K de données supplémentaires. Or en fonction de ce qui précède on a besoin de 4096*log(4096) bits, soit 6K, plus que les données! En passant, ça signifie qu’en de petites données, on peut perdre plus de la moitié de l’information contenu dans la liste initiale !

Bref, personne n’a gagné le petit concours parce que ce n’était tout simplement pas possible.,

Note* : en informatique, log(n) dénote évidemment le binaire ou base 2

Google trie 1 PetaByte de données !

Sat, 22 Nov 2008 00:00:00 +0000

Pour trier un jeu de 72 cartes, je prends une carte de mon jeu mélangé, et je la pose sur la table. J’en prends une seconde, et je la place sur la table avant ou après la première selon l’ordre que je souhaite. La troisième carte peut aller avant ou après les deux premières, ou être insérée entre les précédentes, et ainsi de suite jusqu’à ce que toutes les cartes soient triées dans l’ordre sur la table, ce qui me prend un peu plus d’une minute.

Un TeraByte pour commencer

Dans le même temps de 68 secondes, , améliorant d’un facteur 3 le obtenu plus tôt cette année. Suivant les règles du “ ” proposé par en 1998, les cartes contenaient 100 bytes, ce qui représente au total un TeraByte, l’équivalent, grosso-modo, d’un annuaire qui inclurait tous les habitants de la planète.

Un TeraByte, c’est la capacité d’un gros disque dur actuel, mais on ne peut y lire ou écrire “que” 300 MegaByte par seconde : il faudrait au mieux une heure pour lire les donner à trier dans une mémoire de 1000 GigaByte (qui n’existe pas…) et une autre heure pour réécrire la liste triée, sans compter le temps du tri proprement dit . Google a donc utilisé 1000 ordinateurs, et au moins autant de disques durs formant une partie du “Google File System” , le gigantesque système de stockage de Google.

Trions en parallèle

Mais comment trier les mêmes données à plusieurs? Reprenons le jeu de 72 cartes et divisions le en 2 tas de 36 cartes mélangées, un pour toi, un pour moi. Nous pourrions placer nos cartes sur une seule ligne sur la table et espérer le faire 2 fois plus vite, mais problème peut survenir si nous voulons simultanément insérer nos cartes au même endroit : comment les placer dans le bon ordre dans ce cas ? Soit on doit alors comparer nos deux cartes et éventuellement les intervertir avant de les insérer, soit on doit convenir d’insérer les cartes à tour de rôle, ce qui ralentit considérablement l’opération. Avec 1000 ordinateurs, on ne va pas s’en sortir beaucoup mieux car c’est visiblement l’accès à la table (=mémoire), unique, qui forme un goulot d’étranglement : pas efficace.

Une autre approche serait que je trie mes 36 cartes et toi tes 36 cartes indépendamment, puis que nous réunissions nos deux piles triées, ce qui est très rapide : je pose mes cartes une à une tant qu’elles viennent avant celle que je vois sur le haut de ta pile, et quand je ne peux plus en poser, tu poses les tiennes tant qu’elles viennent avant celle que je ne pouvais plus poser etc.

On peut faire même mieux en échangeant astucieusement nos cartes plutôt que de reformer une seule pile. Si je trie les carreaux et coeur, et toi les trèfles et pique, plus besoin de reformer une pile unique à la fin : commençons par nous échanger les cartes qui n’ont pas la bonne couleur, puis trions nos tas chacun sur notre table, et voilà !

Animation de l’algorithme de tri "quicksort".

QuickSort

Voilà qui ressemble furieusement à l’ illustré ci-contre : on commence par échanger les données plus grande qu’un pivot (seuil bleu) de la première moitié contre celles plus petites que le seuil de la 2ème moitié. Puis on peut répéter l’opération entre le premier quart et le second d’une part, et le 3ème et le 4ème d’autre part, et ainsi de suite. Si on a un nombre de données qui est une puissance de 2, on peut tout trier par simples échanges, et si on dispose aussi d’un nombre de processeurs qui soit une puissance de deux, on peut répartir le travail très efficacement. A quelques variations près, c’est cet algorithme qui est utilisé pour trier de très grosses quantités de données.

MapReduce

S’il y a un sujet sur lesquel j’aurais du me documenter avant d’ , c’est . Le principe est tout simple :

le programmeur écrit :
- une fonction “map” qui sera appliquée à chaque donnée et produira un résultat intermédiaire
- une fonction “reduce” qui regroupera les résultats intermédiaires de “map” pour produire le résultat final
on donne ces deux fonctions à MapReduce, qui se charge de les exécuter de façon efficace sur beaucoup de donnée sur beaucoup de disques durs et beaucoup d’ordinateurs.

Le MapReduce de Google contient en fait un algorithme de partitionnement qui répartir les résultats des “map” sur les “reduce”, et un algorithme de tri incorporé à la partie “Reduce”, car les fonctions “reduce” peuvent presque toujours être rendues plus efficaces si leurs données sont triées. De ce fait, il semblerait que le record du tri ait été obtenu avec une fonction “map” triviale, et une “reduce” qui ne l’est pas moins!

MapReduce est probablement la plus géniale idée des ingénieurs de Google, et une contribution majeure à l’informatique du futur. Le code n’est pas public, mais . D’autre part la fondation Apache a un , qui se base sur , leur équivalent du Google File System. C’est en utilisant ce système + 1000 lignes de Java seulement que Yahoo! a pu trier le TeraByte en 209 secondes . 3x moins bien que Google, c’est quand même pas mal du tout…

Pour en savoir plus sur MapReduce vous pouvez lire la référence , et/ou :

regarder cette vidéo
consulter ces , plus techniques, avec exemple de code et performances

Et un , un !

Une fois qu’on a un stockage distribué (GFS), un système de traitement parallèle massif (MapReduce) et quelques milliers d’ordinateurs, pourquoi se limiter à trier un TeraByte ? Comme ils le disent dans , Google était “curieux de voir ce qui arrive si on essaie avec un PetaByte”. 1000x plus quoi. Juste pour voir…

Ca a pris 6 heures et 2 minutes, soit 21720 secondes sur 4000 ordinateurs. Ramené au même nombre d’ordinateurs, ça a donc pris “seulement” 1277x plus de temps pour trier 1000x plus de données. C’est assez efficace si l’on considère que la complexité d’un algorithme comme QuickSort est O(N.log N) : sur un seul ordinateur, trier 1000x plus de données prend théoriquement 1000x10 = 10'000x plus de temps. Mais en répartissant le tri sur 4 fois plus d’ordinateurs, on divise ce temps par 4 et en plus on divise par 4 la taille des données : on devrait se retrouver avec 250x8/4 = environ 500x plus de temps. Un facteur 1277 c’peut sembler nettement plus, mais c’est normal en raison des communications supplémentaires entre les ordinateurs.

Le tri du PetaByte pose une autre problème intéressant : les données étaient réparties sur 48'000 disques durs et statistiquement, en 6 heures de calcul, au moins un des disques tombe en panne ! Il faut donc que les données triées soient redondantes pour que l’on puisse remplacer le disque fautif sans interrompre l’exécution du tri, ce qui illustre une autre fonctionnalité remarquable du Google File System …

Et après ?

Peu de groupes au monde disposent d’assez de ressources pour tenter de faire mieux que Google. Mais heureusement, les sont ouverts à d’autres catégories:

la catégorie “penny” consiste à trier le plus de nombres possibles pour un “cout” d’un penny, environ 1.3 centimes d’Euro. Le record actuel a été obtenu sur un PC doté d’un AMD 64 sous Linux, mais surtout de 4 disques dur SATA, qui a trié 1'812'000 enregistrements de 100 bytes en 2.408 secondes
la catégorie “Minute” limite le temps de calcul à 60 secondes. Une machine parallèle du MIT a trié 2.140 Milliards d’enregistrements de 100 bytes toujours en 2007.
la catégorie “ ” me semble plus intéressante au niveau du matériel que du logiciel : il s’agit de trier un maximum de nombres par d’énergie consommée par l’ordinateur. Le record appartient à un ordinateur portable utilisant un processeur intel Mobile Core 2 Duo doté de 13 (!) disques durs, et qui trie environ 11'300 enregistrements par Joule . Si les machines de Google avaient la même efficacité énergiétique, le tri du PetyBytes aurait consommé 0.885 GigaJoule, soit 246KWh. Répartis sur 6 jours, ça donne une puissance de 1.7 KW seulement. . Mais avec 4000 gros PC et 48'000 disques durs, Google est probablemet autour de 20x plus.

Et les spaghetti dans tout ça ?

Je ne peux me résoudre à terminer un article sur le tri sans parler du qui m’avait émerveillé il y a près de 25 ans déjà .

Comme on l’a vu plus haut, les meilleurs algorithmes de tri existant ont une complexité O(N.Log N) : le temps de calcul augmente plus vite que le nombre des données, et malgré quelques progrès dus à la parallélisation, il n’existe pas de tri informatique général* en O(N).

Pourtant, des spaghettis pourraient réussir là où les patinent :

on coupe un spaghetti à une longueur représentant le premier enregistrement à trier ramené à un nombre. On coupe un autre spaghetti à la longueur du second nombre, et ainsi de suite pour tous les nombres, et en un temps O(N) on obtient N spaghettis.
on pose verticalement la botte de spaghettis sur une table plane de façon à tasser tous les spaghettis contre la table. Ceci prend un temps constant, très court et indépendant de N et ne compte donc pas dans la complexité globale
En posant une planche enduite de colle sur la botte, on extrait le spaghetti le plus long, on le mesure, on retransforme le nombre en une donnée qu’on écrit au bas de la liste triée et on recommence N fois, pour chaque spaghetti.

Voilà, les spaghettis permettent de trier nos enregistrements en un temps proportionnel à N ! Trier 1000x plus de spaghettis prendra exactement 1000x plus de temps. En fait, si on disposait d’une machine capable de couper puis de mesurer 150 millions de spaghetti à la seconde, elle aurait égalé la machine de Google sur le TeraByte, et l’aurait battu sur le PetaByte, en 18.8 heures seulement :-)

Plus sérieusement, si on a besoin de trier des objets physiques (des grains de sable, des protéines, des ADN ?), il pourrait être intéressant de ne pas oublier la leçon des spaghetti : certains dispositifs physiques peuvent être plus rapides que les plus puissants ordinateurs

Références

Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung “ ”, 19th ACM Symposium on Operating Systems Principles, Lake George, NY, October, 2003.
Jeffrey Dean and Sanjay Ghemawat, “ ” OSDI'04: Sixth Symposium on Operating System Design and Implementation, San Francisco, CA, December, 2004.
Jim Wyllie, “ ”, IBM, February 4, 1999
Owen O’Malley, “ ”, Yahoo!, May 2008
: records de tri de données depuis 1987
“ “ Datamation, V 31.7, April 1985, pp 112-118.
Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz André Barroso, “ ”, Google Inc. Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST’07), February 2007.
Suzanne Rivoire et al. “ ",SIGMOD’07, June 11–14, 2007, Beijing, China
Dewdney, A. K.“On the spaghetti computer and other analog gadgets for problem solving”, Scientific American, (June 1984), 250 (6): 19-26
Niall Murphy et al. “ ”, ,2008, Vol 4 nr 1, pages 3-12

Note* : il existe des algorithmes de tri de complexité linéaire sur des données satisfaisant certaines hypothèses, comme Hervé me l’a fait remarquer dans un commentaire