Les auteurs n'ont pas vraiment de prise sur la maquette...
L'intro, même si elle est bien faite, est un peu trop longue. Je suppose que la taille de l'article est limité, donc il vaut mieux utiliser la place pour les explications qui vont suivre..
Il n'y a pas vraiment de contraintes de places et dans l'article en question, l'intro n'a pas pris la place de la suite. Sinon, je trouve que les intros sont toujours trop courtes. Ici, nous avons voulu bien situer le problème pour que même si quelqu'un ne comprend rien à la suite, il obtienne une vague idée du but et de l'intérêt des réseaux bayésiens, pour décider de s'investir plus tard dans le domaine par exemple.
L'exemple de l'alarme : il y n'y a pas assez d'explications formelles sur les outils mahématiques utilisé, alors que celle sur l'exemple lui même (les voleurs et le camion) abondent. Peut être que beaucoup n'ont pas envie de se taper un cours de math, mais une semi-vulgarisation manque un peu d'intérêt : soit on explique les choses en détail pour pouvoir se passer d'autres doc, soit on en reste à un résumé rapide.
Je ne comprends pas de quoi tu parles. Oui, il n'y a pas de présentation formelle des probabilités, et alors ? Ca ne sert à rien pour faire les calculs et ça n'aide en rien dans la compréhension des mécanismes. Dire qu'une variable aléatoire est une fonction mesurable d'un espace probabilisé dans un espace mesurable ne me semble pas très intéressant pour les lecteurs de lm. Nous avons donc opté pour un résumé rapide et informel.
On ne comprend pas d'où sortent les résultats des tableaux (0.98, 0.05, 0.96...) il aurait fallu être plus clair sur ce qui est choisi arbitrairement et ce qui est calculé.
Autant je suis d'accord sur le fait que les valeurs numériques du premier tableau auraient dues être rappellées dans le texte pour clarifier, autant je ne comprend pas trop la fin de la remarque, étant donné qu'il est clairement indiqué que le tableau 3 est obtenu par calcul.
Les choix de ces valeurs vers la fin ne sont pas très bonnes pour l'exemple : on a pas besoin de faire de calcul pour savoir que l'alarme dans un coin avec peu de voleur et beaucoup de camion risque de faire plus de fausse alerte qu'un dans un coin avec beaucoup de voleur et peu de camion ; un exemple plus ambigu mettant en avant l'utilité d'un calcul quantitatif aurait été plus pertinant. Il aurait été plus clair d'indiquer clairement dès le début ce qu'on veux calculer et à partir de quoi on le fait, çad quelles sont les probabilités déjà connues ; c'est un peu troublant d'être dans le noir toute cette partie et de ne comprendre le sens général qu'à la fin.
Au contraire, les valeurs sont là pour montrer qu'on obtient algorithmiquement un résultat logique et intuitif, et donc qu'on peut reproduire informatiquement le raisonnement humain dans l'incertain. D'autre part, le but de l'exemple est donné dès le départ, je cite "nous allons calculer la probabilité qu'un cambriolage soit en cours dans un magasin dont l'alarme vient de se déclencher". Le fait qu'on indique pas ce qui est connu est parfaitement voulu, il s'agit de faire découvrir au fur et à mesure ce dont on a besoin. Il ne s'agit pas d'un exercice de math...
Le cas général, est très résumé et se contente de renvoyer au référence en fin d'article, alors qu'une implémentatin avec un algo et du code aurait été le bienvenu
Il n'y a rien à dire de particulier sur le cas général, d'ou une présentation très rapide. D'autre part, l'algorithme de base est décrit, donc je ne vois pas le problème. Il est vrai que nous n'avons pas donné d'exemple de code (franchement sans intérêt, vu la masse de code annexe qu'il faut produire pour arriver à un truc super basique résumé par un produit et donc une boucle!). L'ommission du junction tree est délibérée : cet algorithme est extrêmement complexe et demande un article entier de description. De plus, le but de l'article n'est pas de faire programmer un réseau bayésien mais de faire comprendre les concepts.
- enfin, on reprend encore le cas du début en le complexifiant, ce qui aurait plus eu sa place à la suite de la première partie.
Et bien non, justement. Le but est d'illustrer l'intérêt de réseaux plus complexes, pas de compliquer pour le plaisir.
- Il est de plus assez embrouillant de vouloir sortir le nom de tous les algos et techniques en les résumant en une ligne.
Le but de la phrase en question est de donner des pistes à des lecteurs qui connaîtraient un des algorithmes cités, c'est tout.
Bon tout ça en fait, ça fait pas mal de critiques qui sont un peu confuses, et d'autres lecteurs pourraient en fait faire des critiques exactement inverses. Pour résumer je dirais que l'article est trop long pour une introduction, et sans véritable exemple (code, algo...) pour une implémentation, même simple. Il aurait fallu faire un choix clair et s'y tenir.
Le choix était très clair : une introduction qui présente les concepts et les techniques de base sans enfumer le lecteur (i.e. sans lui faire croire qu'il peut tout comprendre en évitant certains concepts mathématiques difficiles). L'algo de base est présent (c'est la section "inférence dans un réseau") et le code ne présente aucun intérêt. De plus, c'est un leurre de croire qu'on peut programmer des réseaux bayésiens sans maîtriser le sujet et l'absence de code est là pour dissuader les lecteurs de le faire.
Voilà, je critique, mais j'espère avoir été constructif, et il y a un peu de mauvaise foi car j'ai quand même trouvé l'article intéressant! :-)
[^] # Re: LinuxMag de ce mois ci : coup de gueule
Posté par boubou . En réponse au journal LinuxMag de ce mois ci : coup de gueule. Évalué à 1.
Les auteurs n'ont pas vraiment de prise sur la maquette...
L'intro, même si elle est bien faite, est un peu trop longue. Je suppose que la taille de l'article est limité, donc il vaut mieux utiliser la place pour les explications qui vont suivre..
Il n'y a pas vraiment de contraintes de places et dans l'article en question, l'intro n'a pas pris la place de la suite. Sinon, je trouve que les intros sont toujours trop courtes. Ici, nous avons voulu bien situer le problème pour que même si quelqu'un ne comprend rien à la suite, il obtienne une vague idée du but et de l'intérêt des réseaux bayésiens, pour décider de s'investir plus tard dans le domaine par exemple.
L'exemple de l'alarme : il y n'y a pas assez d'explications formelles sur les outils mahématiques utilisé, alors que celle sur l'exemple lui même (les voleurs et le camion) abondent. Peut être que beaucoup n'ont pas envie de se taper un cours de math, mais une semi-vulgarisation manque un peu d'intérêt : soit on explique les choses en détail pour pouvoir se passer d'autres doc, soit on en reste à un résumé rapide.
Je ne comprends pas de quoi tu parles. Oui, il n'y a pas de présentation formelle des probabilités, et alors ? Ca ne sert à rien pour faire les calculs et ça n'aide en rien dans la compréhension des mécanismes. Dire qu'une variable aléatoire est une fonction mesurable d'un espace probabilisé dans un espace mesurable ne me semble pas très intéressant pour les lecteurs de lm. Nous avons donc opté pour un résumé rapide et informel.
On ne comprend pas d'où sortent les résultats des tableaux (0.98, 0.05, 0.96...) il aurait fallu être plus clair sur ce qui est choisi arbitrairement et ce qui est calculé.
Autant je suis d'accord sur le fait que les valeurs numériques du premier tableau auraient dues être rappellées dans le texte pour clarifier, autant je ne comprend pas trop la fin de la remarque, étant donné qu'il est clairement indiqué que le tableau 3 est obtenu par calcul.
Les choix de ces valeurs vers la fin ne sont pas très bonnes pour l'exemple : on a pas besoin de faire de calcul pour savoir que l'alarme dans un coin avec peu de voleur et beaucoup de camion risque de faire plus de fausse alerte qu'un dans un coin avec beaucoup de voleur et peu de camion ; un exemple plus ambigu mettant en avant l'utilité d'un calcul quantitatif aurait été plus pertinant. Il aurait été plus clair d'indiquer clairement dès le début ce qu'on veux calculer et à partir de quoi on le fait, çad quelles sont les probabilités déjà connues ; c'est un peu troublant d'être dans le noir toute cette partie et de ne comprendre le sens général qu'à la fin.
Au contraire, les valeurs sont là pour montrer qu'on obtient algorithmiquement un résultat logique et intuitif, et donc qu'on peut reproduire informatiquement le raisonnement humain dans l'incertain. D'autre part, le but de l'exemple est donné dès le départ, je cite "nous allons calculer la probabilité qu'un cambriolage soit en cours dans un magasin dont l'alarme vient de se déclencher". Le fait qu'on indique pas ce qui est connu est parfaitement voulu, il s'agit de faire découvrir au fur et à mesure ce dont on a besoin. Il ne s'agit pas d'un exercice de math...
Le cas général, est très résumé et se contente de renvoyer au référence en fin d'article, alors qu'une implémentatin avec un algo et du code aurait été le bienvenu
Il n'y a rien à dire de particulier sur le cas général, d'ou une présentation très rapide. D'autre part, l'algorithme de base est décrit, donc je ne vois pas le problème. Il est vrai que nous n'avons pas donné d'exemple de code (franchement sans intérêt, vu la masse de code annexe qu'il faut produire pour arriver à un truc super basique résumé par un produit et donc une boucle!). L'ommission du junction tree est délibérée : cet algorithme est extrêmement complexe et demande un article entier de description. De plus, le but de l'article n'est pas de faire programmer un réseau bayésien mais de faire comprendre les concepts.
- enfin, on reprend encore le cas du début en le complexifiant, ce qui aurait plus eu sa place à la suite de la première partie.
Et bien non, justement. Le but est d'illustrer l'intérêt de réseaux plus complexes, pas de compliquer pour le plaisir.
- Il est de plus assez embrouillant de vouloir sortir le nom de tous les algos et techniques en les résumant en une ligne.
Le but de la phrase en question est de donner des pistes à des lecteurs qui connaîtraient un des algorithmes cités, c'est tout.
Bon tout ça en fait, ça fait pas mal de critiques qui sont un peu confuses, et d'autres lecteurs pourraient en fait faire des critiques exactement inverses. Pour résumer je dirais que l'article est trop long pour une introduction, et sans véritable exemple (code, algo...) pour une implémentation, même simple. Il aurait fallu faire un choix clair et s'y tenir.
Le choix était très clair : une introduction qui présente les concepts et les techniques de base sans enfumer le lecteur (i.e. sans lui faire croire qu'il peut tout comprendre en évitant certains concepts mathématiques difficiles). L'algo de base est présent (c'est la section "inférence dans un réseau") et le code ne présente aucun intérêt. De plus, c'est un leurre de croire qu'on peut programmer des réseaux bayésiens sans maîtriser le sujet et l'absence de code est là pour dissuader les lecteurs de le faire.
Voilà, je critique, mais j'espère avoir été constructif, et il y a un peu de mauvaise foi car j'ai quand même trouvé l'article intéressant! :-)
Merci pour ces critiques.