¿Por qué no hay algoritmos de aproximación para SAT y otros problemas de decisión?

Tengo un problema de decisión NP-completo. Dada una instancia del problema, me gustaría diseñar un algoritmo que genere SÍ, si el problema es factible, y, de lo contrario, NO. (Por supuesto, si el algoritmo no es óptimo, cometerá errores).

No puedo encontrar ningún algoritmo de aproximación para tales problemas. Estaba buscando específicamente SAT y encontré en la página de Wikipedia sobre Algoritmo de aproximación lo siguiente: Otra limitación del enfoque es que se aplica solo a problemas de optimización y no a problemas de decisión "pura" como la satisfacción, aunque a menudo es posible ... .

¿Por qué, por ejemplo, no definimos la relación de aproximación como algo proporcional al número de errores que comete el algoritmo? ¿Cómo resolvemos realmente los problemas de decisión de manera codiciosa y subóptima?

Los algoritmos de aproximación son solo para problemas de optimización, no para problemas de decisión.

¿Por qué no definimos la relación de aproximación como la fracción de errores que comete un algoritmo al intentar resolver algún problema de decisión? Debido a que "la relación de aproximación" es un término con un significado estándar bien definido, uno que significa algo más, y sería confuso usar el mismo término para dos cosas diferentes.

Bien, ¿podríamos definir alguna otra relación (llamémosla de otra manera, por ejemplo, "la relación det") que cuantifica el número de errores que comete un algoritmo, para algún problema de decisión? Bueno, no está claro cómo hacerlo. ¿Cuál sería el denominador para esa fracción? O, para decirlo de otra manera: habrá un número infinito de instancias de problemas, y para algunos de ellos el algoritmo dará la respuesta correcta y otros dará la respuesta incorrecta, por lo que terminará con una relación que es "algo dividido por infinito", y eso termina sin sentido o no definido.

Alternativamente, podríamos definir como la fracción de errores que el algoritmo comete, en casos problemáticos de tamaño n . Entonces, podríamos calcular el límite de r n como n → ∞ , si existe dicho límite. Esto seria$r_n$$n$$r_n$$n \to \infty$estar bien definido (si existe el límite). Sin embargo, en la mayoría de los casos, esto podría no ser terriblemente útil. En particular, asume implícitamente una distribución uniforme en las instancias problemáticas. Sin embargo, en el mundo real, la distribución real en las instancias problemáticas puede no ser uniforme, a menudo está muy lejos de ser uniforme. En consecuencia, el número que obtiene de esta manera a menudo no es tan útil como podría esperar: a menudo da una impresión engañosa de lo bueno que es el algoritmo.

Para obtener más información sobre cómo las personas lidian con la intractabilidad (dureza NP), eche un vistazo a Cómo lidiar con la intratabilidad: problemas NP-completos .

La razón por la que no ve cosas como las proporciones de aproximación en los problemas de toma de decisiones es que generalmente no tienen sentido en el contexto de las preguntas que generalmente se hacen sobre los problemas de toma de decisiones. En una configuración de optimización, tiene sentido porque es útil estar "cerca". En muchos entornos, no tiene sentido. No tiene sentido ver con qué frecuencia está "cerca" en un problema de logaritmo discreto. No tiene sentido ver con qué frecuencia está "cerca" de encontrar un isómero gráfico. Del mismo modo, en la mayoría de los problemas de toma de decisiones, no tiene sentido estar "cerca" de la decisión correcta.

Ahora, en implementaciones prácticas, hay muchos casos en los que es útil saber qué parte de los problemas se puede decidir "rápidamente" y qué parte no. Sin embargo, a diferencia de la optimización, no hay una forma única para cuantificar esto. Puede hacerlo estadísticamente, como sugiere, pero solo si conoce la distribución estadística de sus entradas. La mayoría de las veces, las personas que están interesadas en problemas de decisión no tienen tanta suerte de tener tales distribuciones.

Como estudio de caso, considere el problema de detención. Se sabe que el problema de detención es indecidible. Es una pena, porque es un problema realmente útil para poder resolver si está haciendo un compilador. En la práctica, sin embargo, encontramos que la mayoría de los programas son realmente muy fáciles de analizar desde una perspectiva problemática. Los compiladores aprovechan esto para generar un código óptimo en estas circunstancias. Sin embargo, un compilador debe reconocer que existe la posibilidad de que un bloque de código en particular no sea decidible. Cualquier programa que se base en que el código sea "probablemente decidible" puede meterse en problemas.

Sin embargo, la métrica utilizada por los compiladores para determinar qué tan bien resuelven estos casos particulares del problema de detención es muy diferente de una métrica utilizada por un programa de criptografía para probar si un par particular de primos está aceptablemente endurecido contra los ataques. No hay una solución única para todos. Si desea una métrica de este tipo, querrá adaptarla para que se adapte a su espacio de problemas particulares y a su lógica empresarial.

Además de las respuestas existentes, permítanme señalar que hay situaciones en las que tiene sentido tener una solución aproximada para un problema de decisión, pero funciona de manera diferente de lo que piensas.

Con estos algoritmos, solo uno de los dos resultados se determina con certeza, mientras que el otro podría ser incorrecto. Tome la prueba de Miller-Rabin para los números primos , por ejemplo: si la prueba determina que un número no es primo, ese resultado es seguro. Pero en el otro caso solo significa que el número es probablemente primo. Dependiendo de cuánto tiempo de cómputo esté dispuesto a invertir, puede aumentar su confianza en el resultado, pero no será del 100% como lo es para el caso no principal.

Esto es especialmente poderoso cuando se abordan problemas indecidibles: podría escribir una herramienta que intente resolver el problema de detención de un fragmento de código específico. Si puede encontrar una prueba de que el programa no se repetirá sin parar, puede reclamarlo con 100% de certeza. Si no puede encontrar una prueba de este tipo, es posible que el flujo de control del programa sea demasiado complicado para que su herramienta lo analice, pero no es una prueba de que se repetirá para siempre. Al simplificar las estructuras de control, es posible que pueda crear un programa equivalente que sea lo suficientemente simple como para que la herramienta demuestre que se detendrá con seguridad.