Warum gibt es keine Approximationsalgorithmen für SAT und andere Entscheidungsprobleme?

Ich habe ein NP-vollständiges Entscheidungsproblem. Angesichts einer bestimmten Instanz des Problems möchte ich einen Algorithmus entwerfen, der JA ausgibt, wenn das Problem durchführbar ist, und NEIN, andernfalls. (Wenn der Algorithmus nicht optimal ist, treten natürlich Fehler auf.)

Ich kann keine Näherungsalgorithmen für solche Probleme finden. Ich habe speziell nach SAT gesucht und in der Wikipedia-Seite über den Approximationsalgorithmus Folgendes gefunden: Eine weitere Einschränkung des Ansatzes besteht darin, dass er nur auf Optimierungsprobleme und nicht auf "reine" Entscheidungsprobleme wie die Erfüllbarkeit zutrifft, obwohl es häufig möglich ist, .. .

Warum definieren wir das Approximationsverhältnis beispielsweise nicht so, dass es proportional zur Anzahl der Fehler ist, die der Algorithmus macht? Wie lösen wir Entscheidungsprobleme tatsächlich gierig und suboptimal?

Approximationsalgorithmen sind nur für Optimierungsprobleme, nicht für Entscheidungsprobleme.

Warum definieren wir das Approximationsverhältnis nicht als den Bruchteil der Fehler, die ein Algorithmus macht, wenn er versucht, ein Entscheidungsproblem zu lösen? Denn "das Näherungsverhältnis" ist ein Begriff mit einer genau definierten Standardbedeutung, der etwas anderes bedeutet, und es wäre verwirrend, denselben Begriff für zwei verschiedene Dinge zu verwenden.

OK, könnten wir ein anderes Verhältnis definieren (nennen wir es etwas anderes - z. B. "das Det-Verhältnis"), das die Anzahl der Fehler eines Algorithmus für ein Entscheidungsproblem quantifiziert? Nun, es ist nicht klar, wie man das macht. Was wäre der Nenner für diesen Bruch? Oder anders ausgedrückt: Es wird unendlich viele Problemfälle geben, und für einige davon gibt der Algorithmus die richtige Antwort und für andere die falsche Antwort, sodass Sie am Ende ein Verhältnis erhalten, das so ist "Etwas geteilt durch die Unendlichkeit", und das endet damit, dass es bedeutungslos oder nicht definiert ist.

Alternativ könnten wir als den Bruchteil von Fehlern definieren, den Algorithmusfehler bei Probleminstanzen der Größe n . Dann könnten wir die Grenze von r n als n → ∞ berechnen , wenn eine solche Grenze existiert. Das würde$r_n$$n$$r_n$$n \to \infty$gut definiert sein (falls das Limit existiert). In den meisten Fällen ist dies jedoch möglicherweise nicht besonders nützlich. Insbesondere wird implizit eine gleichmäßige Verteilung auf Probleminstanzen vorausgesetzt. In der realen Welt ist die tatsächliche Verteilung auf Probleminstanzen jedoch möglicherweise nicht einheitlich - sie ist häufig sehr weit von der Einheitlichkeit entfernt. Folglich ist die Zahl, die Sie auf diese Weise erhalten, oft nicht so nützlich, wie Sie vielleicht hoffen: Sie vermittelt oft einen irreführenden Eindruck davon, wie gut der Algorithmus ist.

Um mehr darüber zu erfahren, wie Menschen mit Unlösbarkeit (NP-Härte) umgehen, werfen Sie einen Blick auf Umgang mit Unlösbarkeit: NP-vollständige Probleme .

Der Grund, warum Sie bei Entscheidungsproblemen keine Näherungsverhältnisse sehen, ist, dass sie im Allgemeinen im Kontext der Fragen, die Sie normalerweise zu Entscheidungsproblemen stellen, keinen Sinn ergeben. In einer Optimierungseinstellung ist es sinnvoll, "nah" zu sein. In vielen Umgebungen ist dies nicht sinnvoll. Es ist nicht sinnvoll zu sehen, wie oft Sie in einem diskreten Logarithmusproblem "nah" sind. Es ist nicht sinnvoll zu sehen, wie oft Sie dem Auffinden eines Graph-Isomers "nahe" sind. Ebenso ist es bei den meisten Entscheidungsproblemen nicht sinnvoll, der richtigen Entscheidung "nahe" zu sein.

In der Praxis ist es in vielen Fällen hilfreich zu wissen, welcher Teil der Probleme "schnell" entschieden werden kann und welcher nicht. Im Gegensatz zur Optimierung gibt es jedoch keine einheitliche Methode, um dies zu quantifizieren. Sie können dies statistisch tun, wie Sie vorschlagen, aber nur, wenn Sie die statistische Verteilung Ihrer Eingaben kennen. Die meisten Menschen, die an Entscheidungsproblemen interessiert sind, haben nicht das Glück, solche Verteilungen zu haben.

Betrachten Sie als Fallstudie das Halteproblem. Es ist bekannt, dass das Stopp-Problem nicht zu entscheiden ist. Es ist eine Schande, denn es ist ein sehr nützliches Problem, wenn Sie einen Compiler erstellen. In der Praxis stellen wir jedoch fest, dass sich die meisten Programme aus der Perspektive eines haltenden Problems sehr leicht analysieren lassen. Compiler nutzen dies, um unter diesen Umständen optimalen Code zu generieren. Ein Compiler muss jedoch erkennen, dass die Möglichkeit besteht, dass ein bestimmter Codeblock nicht entscheidbar ist. Jedes Programm, dessen Code "wahrscheinlich entscheidbar" ist, kann in Schwierigkeiten geraten.

Die Metrik, mit der Compiler ermitteln, wie gut sie diese besonderen Fälle des Halteproblems lösen, unterscheidet sich jedoch stark von einer Metrik, mit der ein Kryptografieprogramm testet, ob ein bestimmtes Primzahlenpaar akzeptabel gegen Angriffe abgesichert ist. Es gibt keine Einheitsgröße für alle Lösungen. Wenn Sie eine solche Metrik wünschen, sollten Sie sie an Ihre speziellen Probleme anpassen und die Geschäftslogik berücksichtigen.

Lassen Sie mich zusätzlich zu den vorhandenen Antworten darauf hinweisen, dass es Situationen gibt, in denen es sinnvoll ist, eine ungefähre Lösung für ein Entscheidungsproblem zu finden, diese jedoch anders funktioniert, als Sie vielleicht denken.

Mit diesen Algorithmen wird nur eines der beiden Ergebnisse mit Sicherheit bestimmt, während das andere möglicherweise falsch ist. Nehmen Sie zum Beispiel den Miller-Rabin-Test für Primzahlen : Wenn der Test feststellt, dass eine Zahl keine Primzahl ist, ist dieses Ergebnis sicher. Im anderen Fall bedeutet dies jedoch nur, dass die Zahl wahrscheinlich eine Primzahl ist. Je nachdem, wie viel Rechenzeit Sie bereit sind zu investieren, können Sie Ihr Vertrauen in das Ergebnis erhöhen, aber es wird nicht 100% sein, wie es für den Nicht-Prime-Fall ist.

Dies ist besonders hilfreich, wenn Sie unentscheidbare Probleme angehen: Sie können ein Tool schreiben, das versucht, das Problem des Anhaltens eines bestimmten Codeteils zu lösen. Wenn es einen Beweis dafür gibt, dass das Programm keine endlosen Schleifen ausführt, können Sie dies mit 100% iger Sicherheit behaupten. Wenn Sie einen solchen Beweis nicht finden können, kann es sein, dass der Ablauf der Programmsteuerung zu kompliziert ist, um von Ihrem Tool analysiert zu werden, aber es ist kein Beweis dafür, dass er für immer wiederholt wird. Durch die Vereinfachung der Kontrollstrukturen können Sie möglicherweise ein gleichwertiges Programm erstellen, das so einfach ist, dass das Tool nachweisen kann, dass es mit Sicherheit anhält.