Cuisine : polyèdre des ingrédients et enveloppe convexe

Ma cuisine a récemment rejoint ma liste de lieux de découverte et d'émerveillement montpelliérains (après mon labo, ma médiathèque, mon ordinateur, ma salle de concerts et mes cinémas). Pas besoin de tenter d'audacieuses expériences de gastronomie moléculaire pour être fasciné par de simples changements de forme, de couleur et de texture. Que d'émotions à expérimenter la cuisson mutationnelle des choux au Comté, le durcissement de mes fameuses meringues-radiateur, ou une simple montée de blancs en neige au fouet ! Alors rassurez-vous, ce blog ne va pas s'aventurer sur la paillasse d'un chimiste, je ne parlerai ni du pourquoi ni comment ça marche, mais seulement du jusqu'à quel point ça marche ?Rien de plus affirmatif qu'une recette de cuisine : on vous fournit une liste d'ingrédients avec des quantités bien précises, et leur mode d'emploi. Si vous déviez à peine des instructions, aucune garantie, et avec une précision des ingrédients au centigramme, prenez garde que moelleux fondant "merde-j'ai-pu-qu'-deux-oeufs" Marmiton au chocolat ne se transforme en galette compacte.
Heureusement, ce blog va apporter une contribution révolutionnaire pour tous les auteurs de recettes de cuisine : le polyèdre des ingrédients ! Et en bonus une méthode pour le calculer artisanalement à partir d'un corpus de plusieurs recettes du plat que vous voulez, trouvées sur le net par exemple. Illustration du jour : les crêpes ! (oui, je sais, j'aurais dû écrire ce billet il y a 54 jours mais j'ai totalement renoncé à publier à temps mes billets d'actualité...)

Ce qu'il y a de bien dans les crêpes, c'est que ça se fait avec en gros trois ingrédients (plus un pour la poële, qui ne compte pas), ça va donc nous permettre d'obtenir une jolie image en 3D. Des oeufs, de la farine, et du lait, voilà le dénominateur commun aux 19 recettes que j'ai réunies (dans ce fichier tableur) grâce aux sites lejus.com, 1001delices.net, recette-crepe.net, goosto.fr, supertoinette.com, recettes.qc.ca et Marmiton (désolé pour mes amis végétaliens). Mais peut-être va-t-on commencer avec seulement deux ingrédients pour bien comprendre. Disons que l'on a déjà décidé du nombre d'oeufs à utiliser, un seul par exemple. On calcule alors selon toutes les recettes, par une règle de trois, la quantité x de lait et y de farine qu'on doit ajouter (j'ai tout codé en grammes pour simplifier). On peut alors placer sur un graphique cette vingtaine de points de coordonnées (x,y) obtenus :

En bas à gauche se trouvent les recettes avec beaucoup d'oeufs (puisqu'il y a peu de farine et de lait), en haut à droite avec peu d'oeufs. En haut à gauche, plus de farine, en bas à droite, plus de lait. Qu'est-ce donc que cette sorte d'élastique orange qui se resserre autour des points ainsi dessinés ? C'est une sorte de zone de sécurité : tout point de cette zone correspond à un choix d'ingrédients qui devraient fonctionner, puisqu'il se situe "entre" des choix de quantités d'ingrédients qui fonctionnent. En mathématiques, on appelle ça l'enveloppe convexe de l'ensemble de ces points, et il existe des algorithmes variés pour la calculer automatiquement. Alors évidemment, pour ne prendre aucun risque il vaudra mieux cibler bien au milieu de cette enveloppe, vous pouvez d'ailleurs remarquer que 3 recettes présentent les mêmes quantités des trois ingrédients principaux, cela correspond à un point assez central (1/2 litre de lait et 250 grammes de farine pour 3 oeufs).

Autre enseignement de cette enveloppe convexe, on peut en déduire des informations sur la précaution à mesurer chaque ingrédient (la robustesse de la recette en fonction de chaque paramètre en gros). Remarquez combien l'enveloppe convexe est allongée et étroite (elle le serait encore plus si j'avais choisi une échelle verticale et horizontale identiques). Cela signifie que selon les recettes la quantité d'oeufs varie pas mal, mais la proportion lait/farine beaucoup moins. On peut d'ailleurs comparer pour chaque recette ses proportions par rapport aux proportions moyennes :

Et si l'on fait la moyenne de ces pourcentages de variation en valeur absolue, on obtient : 16% pour le rapport lait/farine, 28% pour le rapport farine/oeufs, 31% pour le rapport lait/oeufs. Ainsi le rapport lait/farine varie beaucoup moins que les autres parmi les recettes, il faudra donc être plus méticuleux dans ces proportions que pour le nombre d'oeufs, par rapport à la variation duquel la recette des crêpes est donc plutôt robuste (désolé pour cette structure de phrase alambiquée, mais ça me donne l'occasion de faire un joli accord de pronom relatif).

Vous pouvez aussi vous amuser à représenter sur un même graphique plusieurs desserts ayant les mêmes ingrédients principaux, ici les crêpes, les gaufres et le flan :
Attention tout de même avant de verser votre pâte à crêpes dans le gaufrier ou les ramequins au four, il y a aussi un peu d'huile et de levure dans la préparation à gaufres, et de sucre dans celle du flan.

Pour finir, passons au polyèdre 3D des ingrédients grâce à la très jolie applet Java de Tim Lambert (dont il distribue en plus de code source que j'ai modifié pour y mettre mes points de crêpes), vous pouvez agir avec la souris pour contrôler le polyèdre et le faire bouger :


Sorry, but you need Java to see the animation.

Là encore c'est une enveloppe convexe qui est calculée, en 3 dimensions, sur des points de coordonnées (x,y,z) avec cette fois le nombre d'oeufs en x, la quantité de lait en y, et de farine en z. Je place les points en fixant le nombre d'oeufs à une limite minimum et une limite maximum pour obtenir ce joli tronc de cône, tel que toute coupe perpendiculaire à l'axe x (à nombre d'oeufs constant) me donne bien le polygone d'enveloppe convexe de même forme que ci-dessus. Et pour le rendre vraiment utilisable il faudrait pouvoir laisser entrer à l'utilisateur les valeurs de quantités d'ingrédients qu'il a lui-même utilisées : si le point arrive à l'intérieur du polyèdre, tout va bien, sinon... gare à la recette loupée !

Eh bien il me reste maintenant à attendre le prochain livre de cuisine ou pâtisserie (ou site web) qui accompagnera ses recettes de polygones ou polyèdres d'ingrédients, bizarrement je crois que je devrai faire preuve d'un peu de patience. Encore que... Il y a bien des geeks qui ont programmé un moteur de recherche de recettes de cuisine à partir des ingrédients sur cuistot.org !


Mise à jour en soirée : il me semble naturel que si deux points correspondant à des quantités d'ingrédients fonctionnent pour une recette, alors tout le segment entre ces deux points fait aussi fonctionner la recette, mais certains lecteurs que je ne nommerai pas n'en sont pas convaincus. Tout contrexemple, ou toute théorie alternative quant à la structure, dans l'ensemble à multidimensionnel des ingrédients, des ensembles de points permettant de préparer avec succès un certain plat, sera le bienvenu ! Ce défi du contrexemple est doté d'un prix : une invitation à le déguster (ou bien, si je suis de bonne humeur, à déguster plutôt une des deux extrémités, qui fonctionnent, du segment).

Rétroingéniérie de Google Trends (2) : marge d'erreur

J'avais prévenu dans mon dernier billet, aujourd'hui on parle de choses techniques : la marge d'erreur de mon calcul. Rien de terrible non plus, hein, les calculs sont de niveau lycée... Et en fin de billet, quand même quelques éléments de méthodologie pour minimiser l'erreur. Résumé de l'épisode précédent : j'ai choisi une hiérarchie de termes qui apparaissent de plus en plus haut dans Google Trends, pour évaluer par règles de trois successives le niveau du terme le plus recherché par rapport au moins recherché.

Pour mon calcul je m'étais initialement arrangé instinctivement pour que dans chaque paire de termes consécutifs, le premier ait un maximum environ 2 fois plus haut que le précédent. En effet, la marge d'erreur absolue de lecture de la valeur des courbes est d'environ 1 pixel. Sauf que cette erreur absolue ne correspond pas à la même erreur relative pour la courbe du dessus et celle du dessous. Celle du dessus culmine toujours à 113 pixels : 1 pixel d'erreur c'est donc moins de 1%. Mais pour celle du dessous, si elle culmine à 50 pixels, ça fera 2% d'erreur. Si elle ne dépasse jamais 3 pixels, c'est plus de 30% d'erreur ! Alors dans ce cas, doit-on choisir une hiérarchie de courbes qui sont très proches les unes des autres ? Pas nécessairement, puisque dans ce cas effectivement on réduit l'erreur à chaque étape du calcul, pour deux termes consécutifs, mais on augmente le nombre de termes (et donc d'erreurs successives) entre le moins recherché sur Google, et le plus recherché.

Evidemment, ce délicat compromis que je viens d'exprimer avec des mots, je n'ai pas pu m'empêcher de le modéliser mathématiquement. Je vais appeler a le rapport entre la hauteur max de la courbe la plus haute et celle de la plus basse parmi deux consécutives (et donc a>1). Pour simplifier le problème je considère que dans toute mon échelle de termes, ce rapport est constant. Ainsi, idéalement, j'aimerais trouver un mot 1 cherché x fois par jour sur Google, un mot 2 cherché ax fois par jour, un mot 3 cherché a²x fois par jour... un mot n+1 cherché aⁿx fois par jour.

Maintenant, exprimons cette histoire d'erreur à chaque étape entre deux mots consécutifs : au lieu de lire une hauteur de k pour un mot et ak=113 pour le mot suivant, disons que je me trompe d'un pixel, à chaque fois trop haut (c'est une hypothèse pessimiste, en réalité, l'erreur alterne probablement, une fois on lit trop haut, une fois trop bas, et ça compense...). Pour mon calcul, s'il n'y avait pas d'erreur, par la règle de 3 je devrais trouver comme valeur du nombre de recherches du terme le plus haut :

x.113/k = x.ak/k = xa

Problème, je fais 1 pixel d'erreur, et donc quand j'applique la règle de 3 j'obtiens :

x.113/(k+1) = x.113/(113/a+1) = x.113a/(113+a)

Ainsi à chaque étape je multiplie par 113a/(113+a) au lieu de multiplier par a, donc pour le terme le plus recherché, je trouve x(113a/(113+a))ⁿ au lieu de xaⁿ. Je sous-estime donc la valeur réelle : ainsi pour minimiser l'erreur, je dois maximiser ma valeur calculée, donc trouver la valeur de a>1 qui maximise x(113a/(113+a))ⁿ.

Deuxième partie du raisonnement maintenant : le nombre d'étapes, c'est à dire n+1 termes, certes... mais ce n dépend de a. En effet, considérons qu'on s'est fixés le terme le moins recherché (x fois) et le terme le plus recherché (x'=xaⁿ fois). Alors x'=xe^{n ln a}, d'où ln(x'/x)=n ln a et donc n=ln(x'/x)/ln a.

Injectons ça dans la formule du haut, on a sous-estimé tous les termes de la hiérarchie, et le plus haut a été évalué à :

x(113a/(113+a))^{ln(x'/x)/ln a}

expression qu'on doit donc maximiser par rapport à a. Commençons par une analyse de cette fonction aux limites (mmmmh, les bons souvenirs de première !). En 1⁺, l'intérieur de la parenthèse est inférieur à 1, et l'exposant tend vers +∞, donc l'expression tend vers 0. En +∞, l'exposant tend vers 0, et l'intérieur de la parenthèse vers 113, le tout tend donc vers 1. Ca tombe bien, c'est assez intuitif, ça exprime mathématiquement le dilemme que j'exprimais au second paragraphe... Bon bref, tout ceci ne nous dit pas où se situe son maximum. Et là ni Ahmed le Physicien, ni Julian le Mathématicien, armés respectivement de Mathematica et Maple, ne me fournissent une belle formule, il reste quelques méchants RacineDe(...) dans l'expression.

Pas grave, on va se contenter d'en trouver une approximation à l'aide d'un tableur. Le fichier est ici, et voici la courbe obtenue pour un rapport de 20 000 entre le mot le moins cherché et le plus cherché (c'est de l'ordre de grandeur de celui que j'ai dans ma hiérarchie de termes) :
Ainsi l'erreur minimale est atteinte pour une valeur de a d'environ 2,75 (soit une hauteur maximale de 41 pixels pour la courbe du bas). Elle est alors d'un peu moins de 25%. C'est certes conséquent, mais rappelez-vous qu'on a choisi le scénario où les erreurs se cumulaient par sous-estimation systématique. Alors il me reste cette question théorique intéressante : peut-on calculer l'espérance de l'erreur sur la valeur calculée du terme le plus fréquemment cherché, si à chaque étape l'erreur oscille aléatoirement à chaque mesure entre -1 et +1 pixel ?

On remarque aussi que la courbe croît plus vite à gauche qu'à droite : comme suggéré en vert sur le graphique, il semble qu'il vaudrait mieux choisir une hiérarchie telle que les nombres de recherches des mots de référence consécutifs ont un rapport de 4, plutôt qu'un rapport de 2.

Maintenant, voici quelques autres moyens d'améliorer la précision du calcul. Tout d'abord la précision de la mesure : au lieu de simplement mesurer le maximum où on sait qu'il y a une erreur inévitable, on peut tenter de le calculer à partir de mesures qui contiennent moins d'erreur. Je reprends l'exemple du billet précédent avec cat, dog, et phone:
Comparaison cat ~ dog (courbe 1) : 65 px ~ 113 px
Comparaison dog ~ phone (courbe 2) : 69 px ~ 113 px

Sauf qu'au lieu de mesurer le maximum de dog, on peut l'évaluer de la façon suivante faire la moyenne des valeurs sur la courbe 1 de dog, et la moyenne des valeurs sur la courbe 2 de dog. On en déduit alors un changement d'échelle tout à fait précis. On sait alors que le maximum de dog sur la courbe 1 est atteint à 113 pixels exactement, puisque ça semble être la valeur de référence dans les dessins Google Trends. On multiplie donc cette valeur par le changement d'échelle, et le tour est joué !

Alors maintenant autre problème : comment obtenir la moyenne des valeurs d'une courbe Google Trends ? Avec le CaptuCourbe, évidemment ! Alors là aussi, attention : il arrive que certaines valeurs ne soient pas récupérées par le CaptuCourbe (problème de couleur, par exemple la courbe est coupée par une ligne verticale noire accrochée à une bulle de légende Google News). Il s'agit donc de prendre garde à effectuer la moyenne des deux courbes sur des valeurs bien récupérées !

Autre chose, le CaptuCourbe, par sa méthode de capture, n'est pas très précis puisqu'il récupère tous les pixels de la couleur de la courbe, et en fait la moyenne. J'ai donc développé une nouvelle version, bientôt en ligne, qui permet de récupérer non pas la moyenne mais le max des hauteurs des pixels d'une certaine couleur. C'est cette fonction que j'utilise dans ma méthode pour calculer le max, en revanche c'est toujours celle de la moyenne que j'utilise pour calculer les moyennes des courbes. Ce petit détail n'en est pas un, comme le prouve par exemple la courbe Google Trends de Britney Spears, que j'ai capturée par la méthode du max, et de la moyenne :
Une erreur de 20% dans la mesure de plusieurs pics en utilisant la moyenne des pixels de même couleur, vraiment pas négligeable !

Pour terminer cette série de billets sur l'échelle verticale de Google Trends, il me reste encore quelques questions. Tout d'abord préciser la "valeur du foo". Grâce à des commentaires pertinents sur mon premier billet, je n'en suis pas loin. Je pourrai alors tenter d'automatiser toute la chaîne de récupération de courbes, mesures, et calculs, décrite dans le premier billet, pour fournir un programme qui précise sur une courbe Google Trends à combien de visiteurs correspondent les pics. Ceci dit je ne promets rien, ça vaudrait peut-être le coup d'attendre si l'API que Google prépare fournira ces données.

L'estimation du nombre de recherches pour un mot clé est en tout cas un défi intéressant, j'ai découvert le logiciel gratuit GTrends Made Easy qui propose de telles estimations par une méthode similaire à celle que j'ai présentée ici (en fait il ne fait qu'une seule règle de trois, en comparant le terme cherché avec un mot dont il connaît le nombre de recherches Google par un bon placement Google sur ce mot, et donc se limite aux mots qui apparaissent entre 5 et 50000 fois par jour, c'est à dire inférieurs à 100 foo), qui avait été décrite sur cette vidéo YouTube. Dommage que leurs auteurs n'aient pas poussé leur idée plus loin en enchaînant les changements d'échelle au lieu de se limiter à un.

Dissection d'une pétition (3) : robustesse des résultats

Je reviens sur les résultats de mon dernier billet concernant les tendances horaires d'utilisation d'internet selon la catégorie professionnelle. Quelques éléments de tendance avaient été identifiés, et j'avais avancé dans chaque cas une cause pouvant les expliquer. A quel point ces tendances sont-elles réelles, pourraient-elles être dues à la procédure utilisée pour obtenir les graphiques ?

En général pour vérifier que des résultats trouvés à partir d'analyses statistiques sont corrects, on réeffectue tous les calculs en modifiant légèrement les données. C'est la technique de "rééchantillonnage" ou "bootstrap", particulièrement utilisée en phylogénie (c'est d'ailleurs cette étape de vérification qui traîne et m'empêche de terminer mon billet sur une proposition de "distance Eurovision").

Dans le cas de la pétition TouchePasAMonAdn je ne vais pas modifier les données de départ concernant les signataires, mais plutôt utiliser d'autres règles de regroupement de professions qui donneront donc lieu à un nouveau lot de données. J'avais précisé que les règles que j'avais utilisées pour interpréter les noms de professions entrées par les signataires étaient un peu arbitraires, j'obtenais finalement trois gros groupes (retraités, étudiants, enseignants), et un ensemble de groupes beaucoup plus petits. C'est en tombant sur l'analyse des statistiques sur la pétition EUCD.info que j'ai découvert d'autres règles de groupement de professions qui m'ont semblé meilleures (page 2). Sont-elles effectivement meilleures ? Est-ce qu'en les appliquant on obtient des courbes de tendances similaires ?

Première réponse : oui, les règles d'Eucd sont meilleures, puisqu'elles permettent d'identifier plus de professions. Mes règles personnelles appliquées sur les signataires du 4 octobre permettait de récupérer la profession de 50,5% d'entre eux. Avec les règles d'Eucd.info, j'arrive à 64,3% d'identification de la profession (les signataires de TouchePasAMonAdn ont "mieux" indiqué leur profession que ceux d'Eucd où ils atteignaient seulement 36,6% d'identification). Et en plus de la quantité, la qualité est au rendez-vous : les courbes sont beaucoup plus équilibrées, avec le groupe des "employés" qui passe en première position dans l'ensemble des signataires.

Seconde réponse : oui, les tendances identifiées sont toujours visibles, excepté peut-être le "repas de 13h" des journalistes un peu noyés dans la masse. La disjonction du groupe d'étudiants en post-bac et lycéens/collégiens permet aussi d'identifier une nouvelle tendance sur ces derniers (utilisation d'internet plutôt le soir).

On remarque aussi certaines courbes presque constantes, celles des cadres, des professions libérales, des fonctionnaires, groupes au sein desquels on ne peut donc pas identifier de comportement commun vis à vis de l'utilisation d'internet.

Enfin je m'étais bien gardé de comparer entre différentes professions les pourcentages de signataires trouvés (pour éviter de fausses impressions du genre "ceux qui ont le plus signé la pétition sont les employés", attention j'ai 30% de professions que je n'ai pas identifiées !), mais après cet avertissement je peux me permettre de comparer les pourcentages de signataires par profession avec ceux de la pétition EUCD.info :
Et là les pourcentages de signataires de la pétition TouchePasAMonAdn sont clairement plus représentatifs de la société française que ceux de Eucd.info. Je suis particulièrement étonné par la proportion de retraités : traduit-elle un plus grand intérêt pour cette pétition comme pour les enseignants ou les professions libérales, ou est-ce simplement un reflet de la forte augmentation du "taux de connexion" des retraités depuis 2 ans (la pétition EUCD a commencé fin 2005) ?