Pourquoi n'y a-t-il pas d'algorithmes d'approximation pour SAT et d'autres problèmes de décision?

J'ai un problème de décision NP-complet. Étant donné une instance du problème, je voudrais concevoir un algorithme qui génère OUI, si le problème est réalisable, et NON, sinon. (Bien sûr, si l'algorithme n'est pas optimal, il fera des erreurs.)

Je ne trouve aucun algorithme d'approximation pour de tels problèmes. Je cherchais spécifiquement SAT et j'ai trouvé dans la page Wikipédia sur l' algorithme d'approximation ce qui suit: Une autre limitation de l'approche est qu'elle ne s'applique qu'aux problèmes d'optimisation et non aux problèmes de décision "purs" comme la satisfiabilité, bien qu'il soit souvent possible de .. .

Pourquoi ne définissons-nous pas, par exemple, le rapport d'approximation comme quelque chose de proportionnel au nombre d'erreurs que l'algorithme commet? Comment résoudre réellement les problèmes de décision de manière gourmande et sous-optimale?

Les algorithmes d'approximation sont uniquement destinés aux problèmes d'optimisation, pas aux problèmes de décision.

Pourquoi ne définissons-nous pas le rapport d'approximation comme la fraction d'erreurs qu'un algorithme commet, lorsqu'il essaie de résoudre un problème de décision? Parce que "le rapport d'approximation" est un terme avec une signification standard bien définie, qui signifie autre chose, et il serait déroutant d'utiliser le même terme pour deux choses différentes.

OK, pourrions-nous définir un autre ratio (appelons-le quelque chose d'autre - par exemple, "le ratio det") qui quantifie le nombre d'erreurs qu'un algorithme fait, pour un problème de décision? Eh bien, on ne sait pas comment procéder. Quel serait le dénominateur de cette fraction? Ou, pour le dire autrement: il va y avoir un nombre infini d'instances problématiques, et pour certaines d'entre elles, l'algorithme donnera la bonne réponse et d'autres il donnera la mauvaise réponse, donc vous vous retrouvez avec un ratio qui est "quelque chose divisé par l'infini", et qui finit par être dénué de sens ou non défini.

Alternativement, nous pourrions définir comme étant la fraction des erreurs des erreurs d'algorithme, sur les instances de problème de taille n . Ensuite, nous pourrions calculer la limite de r n comme n → ∞ , si une telle limite existe. Ce serait$r_n$$n$$r_n$$n \to \infty$être bien défini (si la limite existe). Cependant, dans la plupart des cas, cela pourrait ne pas être très utile. En particulier, il suppose implicitement une distribution uniforme sur les instances de problème. Cependant, dans le monde réel, la distribution réelle des instances à problème peut ne pas être uniforme - elle est souvent très loin d'être uniforme. Par conséquent, le nombre que vous obtenez de cette manière n'est souvent pas aussi utile que vous pourriez l'espérer: il donne souvent une impression trompeuse de la qualité de l'algorithme.

Pour en savoir plus sur la façon dont les gens gèrent l'intractabilité (dureté NP), jetez un coup d'œil à Gérer l'intractabilité: problèmes NP-complets .

La raison pour laquelle vous ne voyez pas des choses comme les ratios d'approximation dans les problèmes de prise de décision est qu'ils n'ont généralement pas de sens dans le contexte des questions que l'on pose généralement sur les problèmes de prise de décision. Dans un paramètre d'optimisation, cela a du sens car il est utile d'être «proche». Dans de nombreux environnements, cela n'a pas de sens. Cela n'a pas de sens de voir à quelle fréquence vous êtes "proche" dans un problème de logarithme discret. Cela n'a pas de sens de voir à quelle fréquence vous êtes "proche" de trouver un isomère graphique. Et de même, dans la plupart des problèmes de prise de décision, il n'est pas logique d'être «proche» de la bonne décision.

Maintenant, dans les implémentations pratiques, il existe de nombreux cas où il est utile de savoir quelle partie des problèmes peut être résolue "rapidement" et quelle partie ne peut pas l'être. Cependant, contrairement à l'optimisation, il n'y a pas de moyen unique de quantifier cela. Vous pouvez le faire statistiquement, comme vous le suggérez, mais seulement si vous connaissez la distribution statistique de vos entrées. La plupart du temps, les gens qui s'intéressent aux problèmes de décision ne sont pas aussi chanceux d'avoir de telles distributions.

Comme étude de cas, considérons le problème de l'arrêt. Le problème de l'arrêt est connu pour être indécidable. C'est dommage, car c'est un problème vraiment utile à résoudre si vous faites un compilateur. En pratique, cependant, nous constatons que la plupart des programmes sont en fait très faciles à analyser du point de vue de l'arrêt du problème. Les compilateurs en profitent pour générer un code optimal dans ces circonstances. Cependant, un compilateur doit reconnaître qu'il existe une possibilité qu'un bloc de code particulier ne soit pas décidable. Tout programme qui repose sur un code «probablement décidable» peut avoir des problèmes.

Cependant, la métrique utilisée par les compilateurs pour déterminer leur capacité à résoudre ces cas particuliers du problème d'arrêt est très différente d'une métrique utilisée par un programme de cryptographie pour tester si une paire particulière de nombres premiers est durablement acceptée contre les attaques. Il n'y a pas de solution unique. Si vous voulez une telle métrique, vous voudrez l'adapter à votre espace de problèmes et à votre logique métier.

En plus des réponses existantes, permettez-moi de souligner qu'il existe des situations où il est logique d'avoir une solution approximative pour un problème de décision, mais cela fonctionne différemment que vous ne le pensez.

Avec ces algorithmes, un seul des deux résultats est déterminé avec certitude, tandis que l'autre peut être incorrect. Prenez le test de Miller-Rabin pour les nombres premiers , par exemple: si le test détermine qu'un nombre n'est pas premier, ce résultat est certain. Mais dans l'autre cas, cela signifie seulement que le nombre est probablement premier. Selon le temps de calcul que vous êtes prêt à investir, vous pouvez augmenter votre confiance dans le résultat, mais ce ne sera pas 100% comme pour le cas non-prime.

Ceci est particulièrement puissant lors de la résolution de problèmes indécidables: vous pouvez écrire un outil qui tente de résoudre le problème d'arrêt pour un morceau de code spécifique. S'il peut trouver une preuve que le programme ne bouclera pas indéfiniment, vous pouvez le réclamer avec une certitude à 100%. Si vous ne pouvez pas trouver une telle preuve, il se peut que le flux de contrôle du programme soit trop alambiqué pour que votre outil puisse l'analyser, mais ce n'est pas une preuve qu'il bouclera pour toujours. En simplifiant les structures de contrôle, vous pourriez être en mesure de créer un programme équivalent suffisamment simple pour que l'outil prouve qu'il s'arrêtera à coup sûr.