blog.nraynaud.com Langages

Certains logiciels d'analyse ont une complexité telle qu'obtenir des résultats complets peut être très long. D'un point de vue usage, on peut les re-découper en 2 classes : ceux dont on a absolument besoin qu'ils finissent leur travail pour utiliser les résultats, et ceux dont on peut utiliser les résultats partiels. Un exemple des premiers sont les SAT-solvers utilisés en microélecronique car leur réponse est binaire : soit on peut, soit on ne peut pas couvrir les équations. Comme exemple des seconds, les simulateurs temporels (en électronique analogique par exemple), ils travaillent à temps croissant et donc on peut lire le début des résultats pendant qu'ils calculent le reste. Les logiciels de la première catégorie s'utilisent à la machine à café : 2min de modification des données d'entrée et 2h à la machine à café à attendre les résultats (quand un un algorithme pareil tourne sur la machine, même Word est inutilisable).

La machine à café

Je suis intervenu sur une application issue de la recherche universitaire ayant une forte composante "machine à café", elle délivrait une série de résultats dont chaque fragment était potentiellement très long à calculer. Un des problème est que le logiciel peut renvoyer un résultat 2s, 2h, 10h ou jamais après le résultat précédent. Le "jamais" venant d'une contradiction dans les données d'entrée (aider l'utilisateur à ne pas en faire ou à trouver d'où elle vient est un sujet de thèse). Le problème de ce "jamais" est qu'après un certain temps l'utilisateur n'a plus d'espoir de trouver le reste des résultats, il peut donc arrêter le calcul et aller analyser ses données d'entrée pour comprendre pourquoi. Il suffit d'un seul "jamais" pour que toute la session de calcul laisse l'utilisateur perplexe. Une excellente question est de savoir si le système tourne sans espoir ou s'il est simplement sur un point difficile à trouver mais qu'il peut y arriver.

Le timeout

La solution classique est celle du "timeout" : il s'agit de donner un temps maximal à l'algorithme. Une fois le temps écoulé, on considère qu'il n'y a plus d'espoir de trouver d'autres résultats. Et on laisse l'utilisateur choisir son timeout car il connait ses données d'entrée et sait à quoi s'attendre. Dans l'application, quand une stratégie de calcul ne fonctionne pas, on peut changer de stratégie de calcul. On défini "ça ne fonctionne pas" par : "la moitié du timeout est écoulée". Puis on ajoute une autre stratégie de calcul ce qui donne par : 10% du timeout avec la stratégie 1, 45% avec la stratégie 2 puis 45% avec la stratégie 3. Quand le timeout est passé on arrête de s'acharner et on stoppe tout. Le seul problème est que ce bel édifice repose sur un prémisse faux, l'utilisateur n'a aucune idée à l'avance du temps normal d'analyse de ses données d'entrée, surtout pas avec un algorithme dont certains cas peuvent devenir explosifs (très chaotique).

La suppression du timeout

Probablement la décision tactique la plus chère que j'ai initiée dans ma carrière (je n'ai eu vent du coût qu'après) a été de supprimer le champ texte du timeout de l'interface. L'objectif était simple : plus de timeout, l'utilisateur cliquera sur "stop" quand il pensera qu'il n'y a plus d'espoir de trouver de nouveaux résultats. Et s'il part en vacance en laissant le logiciel tourner, tout ce qu'il risque est une bonne surprise en rentrant. La définition un peu plus formelle est la suivante : il faut que plus le temps s'écoule et plus la probabilité d'obtenir un résultat complet augmente. La stratégie du timeout ne permet pas ceci. Par exemple, si je mets 3j de timeout, certaines stratégies de calcul ne seront testée qu'au bout du 2ème jour. Ceci met un temps minimum à l'obtention de certains résultats faciles. La paralèllisation du calcul étant un autre dossier, elle n'était pas envisageable sur ce sujet. La technique utilisée a donc été de faire tourner toutes les stratégies de calcul pendant un temps croissant : 10s de stratégie 1, 10s stratégie 2, 10s stratégie 3, 1min stratégie 1, 1min stratégie 2, 1min stratégie 3, puis 5min chaque stratégie, etc. Dans l'espoir de toujours trouver le plus facile d'abord.

En revenant de la machine à café

... J'ai trouvé une machine à genoux qui ne répond pas au bouton "stop". Le comportement naturel, c'est d'appuyer sur "stop", puis de retourner prendre un café le temps que la machine répondre, ce qui n'est pas très productif. Un des grand combats techniques a été d'obtenir un bouton "stop" qui réagit immédiatement, même après 3j de calcul. Le scénario désiré était le suivant : l'utilisateur prend son café pendant le calcul, revient, clique sur "stop" et regarde ses résultats. Cela a pris un peu de temps pour expliquer l'intérêt de la chose. Puis, une fois l'intérêt plus ou moins acquis, le combat technique contre le swap, le scheduler ligués contre l'objectif fût long et difficile, mais je pense qu'il a été largement gagné par des développeurs acharnés.

C'est ainsi que les développeurs ont été mobilisés des semaines sans produire de nouveau point sur la liste des fonctionnalités de l'équipe marketing. J'espère aussi vaguement que c'est ce qui a permis à l'entreprise de sortir du secteur très étroit où elle était coincée.

Et l'emballage est assez cool :

Pas mal je trouve.

Afin d'aller avec les petits, sites, j'ai fait des nouvelles cartes de visite, sur le même modèle que les précédentes.

Je pense que ça sera un peu mieux que les anciennes cartes de trainoo.

Pour aider ma copine dans un projet d'architecture, je l'ai aidée à modéliser 2 de ses maquettes, c'était intense, mais marrant au final.

Il s'agissait de 2 propositions pour un Kindergarden.

C'était cool, même si c'est pas du vrai taf :)

Je viens de passer une petite semaine dans des docs à propos d'IEEE 754 et le moins qu'on puisse dire, c'est que le résultat n'est pas brillant.

Qu'est-ce que c'est ?

Il s'agit d'une norme décrivant une représentation des nombres à virgule flottante et des règles de calcul entre eux.

Différentes tailles de mots

La norme définit 4 tailles de mots, avec comme règle : plus c'est petit plus c'est rapide, plus c'est grand, plus c'est précis. Un compromis plutôt intuitif. Pour tous ces mots, elle définit la manière dont on encode les valeurs dedans.

Des valeurs spéciales

Afin de produire un système de calcul consistent, il n'existe pas que des nombres dans ce système.

• les nombres dénormalisés : le système permet de garder encore un peu de précision même quand un nombre est trop près de zéro pour être encodé normalement
• les infinis : + et - l'infini sont représentés, et sont utilisables dans toutes les opérations, atan(+inf) donne pi/2, 1/+inf donne zéro etc.
• le zéro signé : en IEEE 754, le zéro est signé, ce qui permet de maintenir une approche "latérale" sur les fonctions qui ont une asymptote verticale en zéro, par exemple 1/+0 donne +inf
• NaN (not a number) : quand une opération est illégale, cette valeur est retournée. Par exemple 0/0 ou sqrt(-1) renvoient NaN.

Des arrondis

La norme en outre défini des arrondis, qu'on peut demander concernant le calcul. En interne, les calculs sont effectués avec un peu plus de précision que nécessaire, et au moment de couper le nombre pour le faire rentrer dans la taille de mot de l'utilisateur, il faut respecter la règle d'arrondi courante.

• Vers zéro (troncature)
• Vers +infini (ceiling)
• Vers -infini (floor)
• Au plus proche (arrondi). La définition est un poil plus précise ça à cause de certains cas particulier, elle s'appelle round to even. C'est le mode par défaut.

Changer le mode d'arrondi a essentiellement 2 usages : tester la robustesse d'un algorithme ou faire du calcul d'intervalle. La robustesse d'un algorithme c'est savoir "si je change un peu mes données de départ, est-ce que ça change beaucoup mon résultat ?" si la réponse est oui, alors le calcul sera imprécis. Il s'agit de faire exactement l'inverse de Lorentz, on lance un calcul avec plusieurs modes d'arrondis et si les résultats sont trop différents, le calcul n'est pas robuste.
Le calcul d'intervalle consiste à faire tourner 2 fois le calcul, une fois avec un arrondis vers l'+inf et l'autre vers -inf et on sait que la valeur réelle se situe entre les 2. On constate que si l'intervalle est grand, on a l'algorithme n'est pas robuste.

Des évènements

Lors d'un calcul, un certain nombre d'évènements peuvent se produire :

• division par zéro (cet évènement est mal nommé) : il est signalé lorsqu'un infini apparait au résultat alors qu'il n'y avait pas d'infini dans l'entrée. L'exemple classique est 1/0 mais log(0) aussi devrait le produire.
• calcul inexact : cet évènement est très courant, le système passe son temps à arrondir, mais si, par hasard, il lui arrivait de ne pas massacrer un nombre, il ne devrait pas signaler cet évènement.
• opération invalide : l'exemple type est 0/0 mais aussi sqrt(-1) etc.
• overflow : assez explicite, le nombre est trop grand (positivement ou négativement) pour rentrer dans la case, même avec un chausse-pied.
• underflow : lorsqu'un nombre est trop proche de zéro et qu'il va passer en dénormalisé

Lors qu'un évènement survient, la norme suggère 3 types de comportements, par complexité croissante pour l'utilisateur :

• renvoyer une valeur adaptée. Par exemple 0/0 -> NaN, 1/0 -> +inf, un overflow renverra un ±inf etc.
• des flags sont disponibles pour l'utilisateur, après chaque calcul il peut les inspecter, et les remettre à zéro après les avoir vus.
• un listener d'évènement où l'utilisateur peut enregistrer son propre code qui sera exécuté à ce moment.

Un peu de positif

• pour la partie calcul, à peu près tous les langages savent compter avec des nombres
• en général, rallonger une variable (passer de 4 à 8 octets par exemple) offre bien plus de précision

Mais aucun langage ne l'implémente !

• Les développeurs de langages ne sont pas intéressés par IEEE 754.
• Le compromis précision/vitesse n'est en général pas respecté (on peut avoir plus de précision gratuitement)
• Aucun langage n'expose correctement IEEE754 à ses utilisateurs.
• La partie IEEE 754 de la norme C99 n'est pas prise en compte par gcc (face à un exemple qui fonctionnait, un développeur de gcc m'a dit : "c'est de la chance").
• Exposer les évènements de calcul sous forme de signal unix rend leur traitement très compliqué (quel thread à lancé ça ? à quel endroit exactement ?)

Des dangers

Normalement, si un NaN apparait en cours de calcul, les règles font qu'il est propagé. Mais il a un risque de ne pas être vu. En effet, les comparaisons ne propagent pas les NaN dans le calcul. Ainsi 3 < NaN est toujours faux, de même que NaN = NaN qui est toujours faux. D'ailleurs il peut pas en être autrement un booléen est un booléen même chez IEEE 754, il n'existe pas de "NaB" Not a Boolean, donc la comparaison renverra toujours une réponse, cependant, attention à son interprétation.
D'autre part, en ne prenant pas soin du signe des zéros on peut faire apparaitre des infinis avec le mauvais signe, et avoir des résultats abérents.

Les accidents récents du Vendée Globe ont été l'occasion de mettre au clair un certain nombre de conceptions à propos du risque et des tests.

Le but d'une course c'est de gagner, ou de faire au moins un score honorable. Gagner, ça veut dire faire des choix, on peut pas être sur la route nord et la route sud en même temps, on peut pas avoir des outriggers et des barres de flèche en même temps, une quille fixe et une quille mobile etc. En moyenne à la fin de la course, les choix du vainqueur ont été les meilleurs.

Leurs choix

Un des choix, c'est de faire un bateau qui va vite plutôt qu'un bateau qui soit résistant. Ainsi une construction tout inox (ou même tout alu) avec un mât en alu et une quille fixe sont l'option de la sécurité, mais désolé, ça gagne pas un choix comme ça. On peut aussi rester au port quand il y a une tempête dans le Golfe de Gascogne, on peut éviter de se trimballer en solitaire au cap Horn (ce qui est normalement interdit d'ailleurs) etc. Sauf que là le but c'est de gagner la course. Et pour gagner la course, l'état actuel de la technologie, c'est : coque en plastique (epoxy, polyester) renforcé à la fibre (verre ou carbone), un mât en carbone, 2 dérives sabre et une quille mobile, des balasts, une grand voile presque rectangulaire etc. Et ces choix ont leurs inconvénients : c'est fragile, virer de bord est aussi complexe que de faire décoller un 747, c'est inconfortable (à cause de l'étrave verticale), c'est très humide (le bateau est au raz de l'eau donc les vagues et les embruns passent au-dessus). Bref, une formule 1 des mers qui nécessite un brevet d'astronaute pour le pilotage (et j'ai pas parlé du routage et de la sécurité).

On ne peut raisonnablement pas attendre de gens qui ont fait des choix aussi radicaux, qu'ils réussissent tous et en grande proportion. Ils peuvent se tromper à la conception ou avoir des aléas plus tard, se tromper sur le management des équipes etc. Et ça conduit à ce qui c'est produit pendant la première tempête dans le golfe. Tous ceux qui se sont vautrés dans le golfe auraient-il dû appliquer des standards plus stricts à leur bateau ? C'est loin d'être évident : il n'y a eu aucun blessé, aucun naufrage, ils sont tous rentrés de manière autonome au port. Bref, la sécurité des navires n'a pas été mise en cause (ceci ne préjuge pas du reste de la course). Même Hugo Boss avec sa voie d'eau a eu les pompes suffisantes pour rentrer seul sans couler.

Des bateaux à un seul usage

Il est essentiel de distinguer ces bateaux des autres bateaux, ils n'ont un usage ni de plaisance (inconfortables, tirant d'eau de la mort, non manoeuvrants), ni de régate (chiants à manœuvrer, trop grands), ni de marine marchande. On ne va pas les contrôler comme un bateau de marine marchande car ils ont une date de départ fixe et ont une architecture unique, on ne va pas les concevoir comme un bateau de location, car ils sont préparés pour un seul skippeur qui est un expert dans son domaine.

Comme un logiciel

Il fallait y venir, ceci a un lien avec le logiciel : on ne développe pas de la même manière un logiciel pour mettre sur orbite une palanquée d'astronautes et un lecteur de mp3. On ne fait pas les même choix quand on est un constructeur automobile dont les actionnaires espèrent 12% de rendement et zéro risque et une startup dont on espère 500% de rendement et un risque de faillite de 4 chances sur 5. D'autre part il faut savoir compartimenter les risques, un mât qui tombe, ce n'est pas la même chose qu'un naufrage. Les données personnelles des utilisateurs qui sont compromises sont plus graves que l'impossibilité d'exécuter des transactions. Une voiture dont la clim' est en panne, ce n'est pas la même chose qu'un début d'incendie dans l'habitacle etc.

Bref, il faut toujours garder un œil sur les circonstances dans lesquelles on se trouve, et garder les priorités à l'esprit. Sécurité des personnes d'abord, puis des biens, des données, assurer le business c'est le filtre qu'il faut appliquer à nos actions. Et un accident, même impressionnant (mât de 27m qui casse en 3), n'appelle pas toujours à une réaction de type "plus jamais ça, à n'importe quel prix". Il faut savoir vivre avec son risque.

C'est parti, Trainoo.com est ouvert, vous pourrez y suivre votre vie sportive.

Reste à étoffer à mort le service !

Non, désolé, c'est pas encore moi. Mais Vincent qui a ouvert son site, le-musicien.com, il propose un lieu de rencontres entre musiciens mais surtout il indexe des centaines^Wmilliers de partitions gratuites.

Bravo Vincent !

Pour vous donner une idée, il lui a fallu 2 mois pour faire ça alors qu'il est nouveau papa et a un vrai boulot à côté. Il est nettement plus efficace que moi !

On ne peut pas d'un côté interdire la détection de navigateur en JS au profit de la détection de fonctionnalités et de l'autre s'amuser avec des _ ou des * dans le CSS pour éviter ou favoriser le navigateur qu'on cherche (IE 5,6 ou 7).

On ne peut pas parler de portabilité d'affichage (densité de pixels, largeur de l'écran, taille des typos etc.), d'accessibilité et passer son temps à caler tout en taille fixes, même si c'est en em (qui ne résout rien).