Attention, ce n'est pas parce que la fonction HALT n'existe pas qu'on ne peux pas créer un tel filtre bayésien.
Prends l'exemple de l'algorithme de vérification des classes Java. Que fait-il ? En analysant le bytecode d'une classe Java, il décide si ce code est valide ou non. Or ceci revient à déterminer une caractéristique d'un programme, ce qui est impossible si on tient compte de la fonction HALT (et du théorème de l'arrêt et de toute la théorie de la calculabilité).
Or cet algorithme existe bel et bien. Comment est-ce possible ? En fait ce qui se passe c'est que le vérificateur de bytecode est susceptible de refuser une classe Java bien formée. C'est là qu'intervient la fonction HALT.
Ce que dit la calculabilité ce n'est pas qu'il est impossible de créer un algorithme qui calcul une propriété d'unj programme, mais qu'il est impossible de créer un algorithme qui calcule cette propriété avec une certitude absolue !
Dans le cas du vérificateur de bytecode Java, les concepteurs de la JVM ont mis des règles plus restrictives que celles nécessaires pour qu'une classe Java soit valide. Conséquence : de temps en temps une classe est refusée bien que parfaitement valide et sans danger (remarque : cela n'apparaît que chez les gens qui travaillent directement en assembleur pour la JVM, par exemple dans le cadre d'un TFE avec BOBO... Le compilateur Java ne produit, lui, que du bytecode valide)
Donc le risque du filtre bayésien pour les bugs est que si les règles ne sont pas suffisamment restrictives, il ne détecte pas certains bugs, et, dans le cas contraire, il détecte certains bugs qui n'en sont pas.
Mais il est donc bel et bien possible de créer un tel filtre imparfait. Et puis il y a toujours moyen de faire appel à un oracle : l'utilisateur (dans le cas de la JVM, l'oracle c'est le switch "-noverify" qui court-circuite l'algorithme de vérification).
Cette recherche n'est donc pas aussi loufoque qu'elle n'y paraît, sinon adieu aux vérificateurs de code, aux optimiseurs, aux antivirus,...
[^] # Re: Je comprend pas...
Posté par Ze Fredz . En réponse au journal Bayes appliqué au code ?. Évalué à 2.
Prends l'exemple de l'algorithme de vérification des classes Java. Que fait-il ? En analysant le bytecode d'une classe Java, il décide si ce code est valide ou non. Or ceci revient à déterminer une caractéristique d'un programme, ce qui est impossible si on tient compte de la fonction HALT (et du théorème de l'arrêt et de toute la théorie de la calculabilité).
Or cet algorithme existe bel et bien. Comment est-ce possible ? En fait ce qui se passe c'est que le vérificateur de bytecode est susceptible de refuser une classe Java bien formée. C'est là qu'intervient la fonction HALT.
Ce que dit la calculabilité ce n'est pas qu'il est impossible de créer un algorithme qui calcul une propriété d'unj programme, mais qu'il est impossible de créer un algorithme qui calcule cette propriété avec une certitude absolue !
Dans le cas du vérificateur de bytecode Java, les concepteurs de la JVM ont mis des règles plus restrictives que celles nécessaires pour qu'une classe Java soit valide. Conséquence : de temps en temps une classe est refusée bien que parfaitement valide et sans danger (remarque : cela n'apparaît que chez les gens qui travaillent directement en assembleur pour la JVM, par exemple dans le cadre d'un TFE avec BOBO... Le compilateur Java ne produit, lui, que du bytecode valide)
Donc le risque du filtre bayésien pour les bugs est que si les règles ne sont pas suffisamment restrictives, il ne détecte pas certains bugs, et, dans le cas contraire, il détecte certains bugs qui n'en sont pas.
Mais il est donc bel et bien possible de créer un tel filtre imparfait. Et puis il y a toujours moyen de faire appel à un oracle : l'utilisateur (dans le cas de la JVM, l'oracle c'est le switch "-noverify" qui court-circuite l'algorithme de vérification).
Cette recherche n'est donc pas aussi loufoque qu'elle n'y paraît, sinon adieu aux vérificateurs de code, aux optimiseurs, aux antivirus,...