Et bien voilà, ce matin est arrivée une belle vidéo illustrant ce que sera Android 3.0 (Honeycomb), et je dois avouer que contrairement à ce que je pensais, je ne suis pas déçu, bien au contraire ! Les fameuses 4 touches d'Android (parfois 3), à savoir Back, Menu, Home, et Search ne seront effectivement plus obligatoires, car intégrées directement dans l'interface. L'iPad n'a qu'à se tenir !

Sans plus attendre, je vous laisse découvrir la vidéo :

Et vous, vous en pensez quoi ?

Via googlesystem.blogspot.com

On peut alors s'amuser à prendre 1 valeur au hasard, trouver son hashé, et ensuite utiliser cette nouvelle valeur comme valeur de départ, prendre son haché, etc... Là, on est sûr de trouver, au bout d'un temps potentiellement très long, une boucle (ou un cycle), comme sur l'image suivante (prise de wikipedia) :

La façon naïve de faire va être de stocker chacune des valeurs, et de comparer la nouvelle valeur avec toutes les valeurs précédentes. Si on veut éviter d'exploser en temps, on peut utiliser des énormes tables de hash. Sauf que voilà, il faut stocker toutes les valeurs, et on est donc en O(n) pour l'espace mémoire, n étant le nombre de valeurs avant qu'on ne cycle.

Je repose donc la question : comment peut-on effectuer le même traitement en O(1) pour l'espace mémoire ?
Pas forcément intuitive, l'algorithme est au final particulièrement simple et élégant. Il a été défini par Floyd, et on le connait sous le nom d'algorithme du lièvre et de la tortue.

On peut écrire les opérations que l'on fait pour avancer sur la chaine sous la forme a_i+1 = f(a_i), f étant la fonction qu'on utilise (fonction de hash dans l'exemple que j'ai donné). Mais au lieu d'itérer une seule fois sur la chaine, on va en fait lancer 2 itérations en parallèle :

• La tortue avance lentement, donc à chaque itération elle fait a_i+1 = f(a_i)
• Le lièvre est très rapide, il va donc avancer 2 par 2, avec b_i+1 = f(f(b₁))

De façon évidente, le lièvre va arriver dans le cycle avant la tortue, et va se retrouver à tourner dedans en attendant que la tortue n'arrive... Une fois que la tortue est dans le cycle, on a la garantie qu'elle va arriver à la même valeur que le lièvre au bout d'un temps donné, puisque qu'en fait le lièvre rattrape la tortue d'1 étape à chaque itération. Quel que soit l'écart entre les 2, une fois que la tortue arrive dans le cycle le lièvre sera sur le même noeud en au plus L itérations (L étant la taille du cycle).

Et du coup, on n'a besoin d'aucune mémoire supplémentaire pour savoir où est le cycle !
Le pseudo-code, pris de wikipedia, est le suivant :
mu := 0;
répéter
  mu := mu+1;
  x := f(x);
  y := f(f(y));
tant que x <> y
On peut difficilement faire plus simple...

Le seul défaut de cette méthode est la complexité : on reste en O(n), mais on va tout de même appeler 3*n fois la fonction f. Mais cette constante reste relativement faible par rapport au gain en mémoire (on passe de O(n) à O(1)...).

Plus d'informations sur wikipedia

• On ouvre un flux sur "/dev/dsp"
• On le configure
• Libmad décompresse le mp3 petit à petit, et à chaque morceau décompressé on le balance dans /dev/dsp
• On referme le flux quand on a fini...

Parfois ça quittait dès le départ, et parfois on avait genre 1/4 de seconde du mp3 avant que ça ne quitte... On a rapidement repéré à quel endroit ça quittait : au moment d'écrire dans /dev/dsp (par blocs de 8192 octets), ça s'arrêtait très rapidement avec un message d'erreur : "Interrupted System Call".

Alors, à quoi correspond ce message ? En fait c'est tout simple : on a fait un appel système (ici, l'écriture dans /dev/dsp) qui a été interrompu par un signal... L'écriture dans /dev/dsp n'est en fait pas une opération atomique, donc on n'a aucune garantie qu'elle puisse se dérouler complètement en une seule fois.

La solution a mettre en place est assez basique : au lieu de quitter à la moindre interruption, on note combien d'octets ont déjà été écrits, on incrémente le pointeur d'autant, on décrémente la taille à écrire, et on relance le fwrite... Et ça marche !

Merci au site suivant pour la petite explication claire et précise : http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch10lev1sec5.html

Note au passage : c'est marrant de voir comment tout est flux sur Unix... Du coup, pour jouer un son, c'est aussi un simple flux dans lequel on envoie les données du son à jouer. On peut même faire un "cat toto.wav > /dev/dsp" et entendre son wav :p

Alors certes, pourquoi pas, mais on se rend compte qu'en règle général on a du mal à imaginer les écarts de temps... Un accès à une valeur du cache L2, est-ce vraiment beaucoup plus lent que pour le cache L1 ? Et que pour un accès en RAM ? Il existe donc un petit tableau "comparatif", histoire que tout programmeur puisse se faire une idée de l'importance de ce genre d'optimisations...
Je ne l'ai pas traduit car de toute façon c'est relativement simple à comprendre, je vous laisse donc vous instruire

Un petit commentaire ? A la louche, un facteur 14 entre les accès au cache L1 et les accès au cache L2, et à nouveau un facteur de cet ordre pour un accès en mémoire principale. Comme quoi ça coûte vraiment cher !

Source : The Axis of Eval

J'ai regardé les réponses par curiosité, et je dois avouer que certaines me correspondent bien. J'ai testé avec ma copine, et dans l'ensemble elle approuve (avec une mention spéciale pour une réponse en particulier). Voici donc un petit panel rapide et non exhaustif :

• Utilisation des parenthèses imbriquées (je dois admettre que je le fais assez souvent (et même dans ce billet !))
• Temps de latence anormalement long pour répondre à des questions pourtant très simples, du style "tu veux du thé ?". Ma copine râle beaucoup à propos de ça... Certains disent que c'est parce qu'il faut le temps de faire le pre-processing, l'analyse lexicale et syntaxique, et l'optimisation de la réponse, mais pour ma part je dirai que c'est juste que quand je suis concentré sur du code (ou un domaine relatif à la programmation) je suis un peu dans un mode de particulier (logique et proche de la machine, on va dire), et que du coup, effectivement, ça interrompt un peu le fil de ma pensée et il me faut un temps pour me "reconnecter". D'ailleurs, dans ma tête, souvent je suis en train de taper du code, et là ça fait "tiens, on me parle"... je continue à taper un peu, et puis au bout d'un même je switch sur le mode "social" et je réponds. Mais ça énerve ma copine d'attendre plus d'1 seconde pour ça.
• Numérotation qui commence à 0. Je ne comprends d'ailleurs toujours pas pourquoi dans les éditeurs de code on numérote à partir de 1...
• Pour un programmeur, 256 est un chiffre rond. Là je ne dirai que ce n'est pas forcément vrai pour tous les programmeurs, mais en tout cas pour ceux qui font pas mal de C/C++. En Java, je le vois beaucoup moins.
• Le fait de revenir en arrière dans la call stack de la conversation. Ca j'ai tendance à le faire et c'est vrai que les gens n'aiment pas beaucoup, dans l'ensemble. Du style si je pensais à quelque chose à dire à un moment donné et qu'entre temps quelqu'un a parlé et que la conversation à avancé, dans ma tête c'est toujours présent, et à tout moment s'il y a un blanc je vais avoir tendance à revenir en arrière dans la conversation pour repartir de là où j'avais quelque chose à dire.

Il y a pas mal d'autres réponses sympas sur le site, donc si vous avez un peu de temps à perdre, je vous invite à aller voir ça

Voici donc une petite fonction qui peut se révéler utile lorsqu'on fait du debug

#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>

/* Obtain a backtrace and print it to stdout. */
void
print_trace (void)
{
  void *array[10];
  size_t size;
  char **strings;
  size_t i;

  size = backtrace (array, 10);
  strings = backtrace_symbols (array, size);

  printf ("Obtained %zd stack frames.\n", size);

  for (i = 0; i < size; i++)
     printf ("%s\n", strings[i]);

  free (strings);
}

Ca m'a bien dépanné, et même si je ne m'en suis pas tellement servi au final (juste une fois), je pense que ça fait parti des petits bouts de code toujours utiles à avoir sous le coude...

Pour plus de détails, je vous invite à vous rendre sur le site de GNU.

Je vais commencer par ce qui me parait être le plus sympa, alors voilà, les magic number dans toute leur splendeur... On est dans une classe "Image", qui possède des getters pour largeur et hauteur :

// fix for null images
width(){
	if (myWidth > 2000)
		return 39;

	return myWidth;
}

Je vous épargne le reste du code, on a exactement la même chose pour la hauteur Pourquoi cette limite à 2000 ? Et pourquoi retourner 39 dans ce cas ? Aucune idée ! J'aime beaucoup le commentaire, par contre :p

Dans un registre un peu moins grave, une partie du code qui est copiée/collée un peu partout, et qui sert à convertir une valeur sur 8 bits (de 0 à 255, pour un niveau de gris) en 4 valeurs (0x00, 0x40, 0x80, et 0xC0) :

if (pixel < 64)
	pixel = 0x00;
else if (pixel < 128)
	pixel = 0x40;
else if (pixel < 192)
	pixel = 0x80;
else
	pixel = 0xC0;
	

Alors, cette fois-ci au moins on comprend le code, à quoi il sert. Par contre, ça fait 8 lignes copiées/collées à une dizaine d'endroits différents, ce n'est pas terrible, d'autant plus que ça revient juste à retirer les bits de poids faible :

pixel &= ~63;

Je me demande si GCC est capable d'optimiser ça, d'ailleurs.

Un petit dernier pour la route, mais cette fois-ci, ce n'était pas du code taiwanais, c'était du beau code de la fac :p. Vu dans une méthode :

if (this == null){
	doSomething();
} else {
	doSomethingElse();
}

Un avis ?

Jusque là, rien d'anormale... Certes... Sauf qu'en fait, au milieu de la vidéo on voit sur un tableau une équation à la con, et du coup des personnes de chez Jamendo se sont amusées à la résoudre... Je vais vous laisser lire la suite sur leur blog, mais pour faire simple, on obtient une fraction qui peut être convertie en URL, et en allant sur cette URL... Un portable sous Chrome OS est offert ! Bon, c'est trop tard, c'était uniquement pour le premier venu, mais je trouve ça sympa d'avoir mis un easter egg en plein milieu de la vidéo.

Bravo à Google, et puis surtout bravo à ceux qui ont trouvé la réponse, il fallait le faire !

C'est sympa car très visuel, en fait, on voit la progression au fur et à mesure, avec le petit graph pour montrer ce que ça donne.

Premier essai...

Quand je suis tombé dessus ce matin, je me suis dit que j'allais laisser tourner le programme quelques heures histoire que ça évolue bien et que ça donne une voiture super efficace. J'ai regardé de temps en temps, et voici ce que j'ai pu voir :

• Premières générations super aléatoires, car les roues ne sont pas forcément en bas !
• Après 2-3 générations, la majorité des voitures générées ont au moins 1 roue en bas
• Après une dizaine de générations, les voitures comment à pas mal avancer, mais l'évolution a été bizarre : elles ont toutes une roue en bas, et les poids sont mis de façon à équilibrer la voiture pour rouler ainsi. Du coup ça n'avance pas super loin car s'il y a trop de relief ça tombe
• A un moment est apparue la première voiture avec 2 roues en bas, qui est allée 2 fois plus loin que les autres ! Mais les mutations à la génération suivante ont fait que les 2 roues du bas étaient très mal placées, du coup elle est allée moins loin que les voitures à 1 roue et a disparu...
• Après quelques dizaines d'évolutions, les voitures à 2 roues ont remplacé les voitures à 1 roue, en gardant une disposition des poids similaires à celle des voitures à 1 roue
• Après un peu de temps, une voiture beaucoup plus large que les autres est apparue, elle est beaucoup plus apte a franchir les obstacles, et a imposé son génome en 2-3 générations.

Et en gros à partir de là, très peu d'évolution. Toutes les voitures sont sensiblement identiques, dès qu'une voiture un peu différente est générée, elle est moins bonne. Au final, j'étais déçu car aucune ne parvenait à passer le creux qu'on voit sur l'image au-dessus : elles se retournaient toutes.

On peut faire mieux ?

J'ai fini par me dire que ça pourrait être sympa de recommencer pour voir si l'évolution peut faire mieux. Et là, radicalement différent :

• Première génération, une voiture à 2 roues en bas qui avance un peu
• Deuxième génération, plusieurs voitures à 2 roues assez efficaces, le génome se répand rapidement !
• Cinquième génération, les voitures arrivent aussi loin que celles d'avant après une centaine de générations (...)
• Huitième génération (à la louche), les voitures passent le creux et vont plus loin ! (comme on le voit sur l'image ci-dessus)

C'est allé super vite ! En fait, du fait que les bonnes mutations soient arrivées très tôt, l'ensemble des voitures était encore composé de voitures très différentes, et le brassage a donc fait évoluer les choses très rapidement. Dans le cas précédent, tout avait évolué lentement, menant à des générations beaucoup trop homogène. C'est donc bien de la différence et de la diversité que vient la force des algorithmes génétiques.

Une fois qu'une génération est arrivée dans un optimum local, il devient très difficile d'en sortir, car toutes voiture qui est différente est potentiellement moins bonne, et donc va être oubliée... C'est d'ailleurs ce que je voyais sur le graph de progression : l'évolution se faisait par "breakthrough", comme on dit, avec de grands pas d'évolution d'un coup. Il faut qu'une voiture apporte une énorme amélioration sur les autres pour qu'elle soit gardée et que son génome soit passé à tout le monde au bout de quelques générations...

A l'occasion je m'attaquerai un peu à ce genre de programmation, je trouve ça très sympa, pas forcément difficile à faire (plus difficile à tweaker pour trouver la bonne taille de population, le bon taux de mutation, etc.), et puis visuellement c'est sympa à regarder (ça ferait un bon screensaver d'ailleurs).

Ce qu'il a d'intéressant, ce qu'il y a expose des problèmes avec des énoncés très courts, qui sont en fait globalement des problèmes d'algorithmique simple que l'on peut avoir en entretien d'embauche. Bon, moi les entretiens je m'en fous, mais les problèmes sont tous de mini-casse-têtes, intéressants à résoudre, et il y apporte des solutions souvent originales, et parfois des discussions annexes intéressantes.

Je vais surement reprendre ici certain des problèmes dans les semaines à venir. Et si jamais je suis très motivé je ferai les codes correspondants en Caml !