Perché non ci sono algoritmi di approssimazione per SAT e altri problemi decisionali?

Ho un problema decisionale NP-completo. Data un'istanza del problema, vorrei progettare un algoritmo che genera SÌ, se il problema è fattibile e, NO, altrimenti. (Naturalmente, se l'algoritmo non è ottimale, commetterà errori.)

Non riesco a trovare alcun algoritmo di approssimazione per tali problemi. Stavo cercando specificamente SAT e ho trovato nella pagina Wikipedia sull'algoritmo di approssimazione quanto segue: Un'altra limitazione dell'approccio è che si applica solo a problemi di ottimizzazione e non a problemi di decisione "puri" come la soddisfacibilità, sebbene spesso sia possibile .. .

Perché, ad esempio, non definiamo il rapporto di approssimazione come qualcosa di proporzionale al numero di errori che l'algoritmo commette? Come possiamo effettivamente risolvere i problemi decisionali in modo avido e non ottimale?

Gli algoritmi di approssimazione sono solo per problemi di ottimizzazione, non per problemi di decisione.

Perché non definiamo il rapporto di approssimazione come la frazione di errori commessa da un algoritmo quando si cerca di risolvere qualche problema decisionale? Perché "il rapporto di approssimazione" è un termine con un significato ben definito e standard, uno che significa qualcos'altro, e sarebbe confuso usare lo stesso termine per due cose diverse.

OK, potremmo definire qualche altro rapporto (chiamiamolo qualcos'altro, ad esempio "det-ratio") che quantifica il numero di errori che un algoritmo commette, per qualche problema decisionale? Bene, non è chiaro come farlo. Quale sarebbe il denominatore per quella frazione? Oppure, per dirla in un altro modo: ci sarà un numero infinito di istanze problematiche, e per alcune di esse l'algoritmo darà la risposta giusta e altre darà la risposta sbagliata, quindi finirai con un rapporto che è "qualcosa diviso per l'infinito", e che finisce per essere insignificante o non definito.

In alternativa, potremmo definire come la frazione di errori degli errori dell'algoritmo, su istanze problematiche di dimensione n . Quindi, potremmo calcolare il limite di r n come n → ∞ , se esiste un tale limite. Questo sarebbe$r_n$$n$$r_n$$n \to \infty$essere ben definito (se esiste il limite). Tuttavia, nella maggior parte dei casi, questo potrebbe non essere terribilmente utile. In particolare, assume implicitamente una distribuzione uniforme sulle istanze problematiche. Tuttavia, nel mondo reale, l'effettiva distribuzione sulle istanze problematiche potrebbe non essere uniforme - è spesso molto lontana dall'uniforme. Di conseguenza, il numero che ottieni in questo modo spesso non è così utile come potresti sperare: spesso dà un'impressione fuorviante di quanto sia buono l'algoritmo.

Per saperne di più su come le persone affrontano l'intrattabilità (durezza NP), dai un'occhiata a Come trattare l' intrattabilità: problemi NP-completi .

Il motivo per cui non si vedono cose come i rapporti di approssimazione nei problemi decisionali è che generalmente non hanno senso nel contesto delle domande che si pongono in genere sui problemi decisionali. In un'impostazione di ottimizzazione, ha senso perché è utile essere "vicini". In molti ambienti, non ha senso. Non ha senso vedere quanto spesso sei "vicino" in un problema di logaritmo discreto. Non ha senso vedere quanto spesso sei "vicino" alla ricerca di un isomero grafico. Allo stesso modo, nella maggior parte dei problemi decisionali, non ha senso essere "vicini" alla decisione giusta.

Ora, nelle implementazioni pratiche, ci sono molti casi in cui è utile sapere quale parte dei problemi può essere decisa "rapidamente" e quale parte no. Tuttavia, a differenza dell'ottimizzazione, non esiste un metodo unico per quantificarlo. Puoi farlo statisticamente, come suggerisci, ma solo se conosci la distribuzione statistica dei tuoi input. Il più delle volte, le persone interessate a problemi di decisione non sono così fortunate ad avere tali distribuzioni.

Come caso di studio, considera il problema dell'arresto. È noto che il problema dell'arresto è indecidibile. È un peccato, perché è un problema davvero utile da risolvere se stai facendo un compilatore. In pratica, tuttavia, scopriamo che la maggior parte dei programmi sono in realtà molto facili da analizzare dal punto di vista del problema. I compilatori ne approfittano per generare codice ottimale in queste circostanze. Tuttavia, un compilatore deve riconoscere che esiste la possibilità che un determinato blocco di codice non sia decidibile. Qualsiasi programma che si basa sul fatto che il codice sia "probabilmente decidibile" può avere problemi.

Tuttavia, la metrica utilizzata dai compilatori per determinare quanto riescono a risolvere questi casi particolari del problema di arresto è molto diversa da una metrica utilizzata da un programma di crittografia per verificare se una particolare coppia di numeri primi è accettabilmente indurita contro gli attacchi. Non esiste una taglia unica per tutte le soluzioni. Se si desidera una tale metrica, sarà necessario adattarla per adattarsi ai propri problemi specifici, spazio e logica aziendale.

Oltre alle risposte esistenti, vorrei sottolineare che esistono situazioni in cui ha senso avere una soluzione approssimativa per un problema decisionale, ma funziona diversamente da come si potrebbe pensare.

Con questi algoritmi, solo uno dei due risultati viene determinato con certezza, mentre l'altro potrebbe non essere corretto. Fai il test di Miller-Rabin per i numeri primi , ad esempio: se il test determina che un numero non è un numero primo, quel risultato è certo. Ma nell'altro caso significa solo che il numero è probabilmente primo. A seconda di quanto tempo di calcolo sei disposto a investire, puoi aumentare la tua fiducia nel risultato, ma non sarà del 100% come nel caso non primario.

Ciò è particolarmente efficace quando si affrontano problemi indecidibili: è possibile scrivere uno strumento che tenta di risolvere il problema di arresto per un determinato pezzo di codice. Se riesce a trovare una prova del fatto che il programma non si ripeterà all'infinito, puoi richiederlo con certezza al 100%. Se non riesci a trovare una tale prova, potrebbe darsi che il flusso di controllo del programma sia troppo contorto per poter essere analizzato dal tuo strumento, ma non è una prova che si ripeterà per sempre. Semplificando le strutture di controllo, potresti essere in grado di creare un programma equivalente che è abbastanza semplice da consentire allo strumento di provare che si arresterà per certo.