Esiste un sottoinsieme di programmi che evita il problema dell'arresto

21

Stavo solo leggendo un'altra spiegazione del problema di arresto, e mi ha fatto pensare a tutti i problemi che ho visto che sono riportati come esempi che coinvolgono sequenze infinite. Ma non uso mai sequenze infinite nei miei programmi: impiegano troppo tempo. Tutte le applicazioni del mondo reale hanno limiti inferiori e superiori. Anche i reali non sono veri: sono approssimazioni memorizzate come 32/64 bit ecc.

Quindi la domanda è: esiste un sottoinsieme di programmi che può essere determinato se si fermano? È abbastanza buono per la maggior parte dei programmi. Posso costruire un insieme di costrutti linguistici che posso determinare l '"haltability" di un programma. Sono sicuro che questo è stato studiato da qualche parte in precedenza, quindi qualsiasi suggerimento sarebbe apprezzato. La lingua non sarebbe completa, ma esiste qualcosa di quasi completo che è abbastanza buono?

Abbastanza naturalmente un tale costrutto dovrebbe escludere la ricorsione e unbound illimitato mentre i loop, ma posso scrivere un programma senza quelli abbastanza facilmente.

La lettura dell'input standard come esempio dovrebbe essere limitata, ma è abbastanza facile: limiterò il mio input a 10.000.000 di caratteri, ecc., A seconda del dominio del problema.

tia

[Aggiornare]

Dopo aver letto i commenti e le risposte forse dovrei riaffermare la mia domanda.

Per un determinato programma in cui tutti gli ingressi sono limitati, è possibile determinare se il programma si interrompe. In tal caso, quali sono i vincoli della lingua e quali sono i limiti del set di input. L'insieme massimo di questi costrutti determinerebbe un linguaggio che può essere dedotto per fermarsi o meno. C'è stato qualche studio su questo?

[Aggiornamento 2]

ecco la risposta, sì, nel lontano 1967 da http://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf

Che il problema dell'arresto possa almeno essere teoricamente risolto per i sistemi a stati finiti è già stato sostenuto da Minsky nel 1967 [4]: “... qualsiasi macchina a stati finiti, se lasciata completamente a se stessa, finirà per cadere in un periodico perfettamente periodico modello ripetitivo. La durata di questo schema ripetuto non può superare il numero di stati interni della macchina ... "

(e quindi se ti attacchi a macchine da turismo finite, puoi costruire un oracolo)

algorithms computer-science

— daven11
fonte

13

"sequenze infinite ... impiegano troppo tempo". Mi ha fatto ridere ad alta voce.

— Bryan Oakley,

3

Credo che SQL92 e le espressioni regolari siano esempi di linguaggi che si fermeranno sicuramente.

— Elian Ebbing,

2

Si prega di inviare "Update2 ..." come risposta.

— S.Lott

2

Non è necessario escludere la ricorsione. Se limiti la ricorsione a rigorosi sotto-termini degli argomenti chiamati, sarai sempre in grado di provare la risoluzione. È un requisito sufficiente: non sono necessari "loop limitati" e simili, purché si utilizzino i numeri della Chiesa.

— Logica SK

1

La lingua che Idris utilizza la digitazione dipendente e un correttore di prove per provare a terminare i programmi prima di eseguirli. È simile a Haskell e consente la ricorsione, ma non la ricorsione generale : solo la ricorsione che può provare (attraverso i tipi dipendenti) porta ad uno stato terminale.

— Jack,

8

Il problema non riguarda l'input (ovviamente, con l'input illimitato, puoi avere un tempo di esecuzione illimitato solo per leggere l'input), è sul numero di stati interni.

Quando il numero di stati interni è limitato, teoricamente puoi risolvere il problema di arresto in tutti i casi (basta emularlo fino a quando non raggiungi l'arresto o la ripetizione di uno stato), quando non lo è, ci sono casi in cui non è risolvibile . Ma anche se il numero di stati interni è in pratica limitato, è anche così enorme che i metodi che fanno affidamento sul limite del numero di stati interni sono inutili per dimostrare la fine di tutti i programmi tranne quelli più banali.

Esistono modi più pratici per verificare la chiusura dei programmi. Ad esempio, esprimili in un linguaggio di programmazione che non ha ricorsività né goto e le cui strutture di ciclo hanno tutti un limite al numero di iterazioni che devono essere specificate al momento dell'ingresso del ciclo. (Si noti che il limite non deve essere realmente correlato al numero effettivo di iterazioni, un modo standard per dimostrare la fine di un ciclo consiste nell'avere una funzione che si dimostra stia diminuendo da una iterazione all'altra e la propria condizione di ingresso assicurati che sia positivo, potresti mettere la prima valutazione come tuo limite).

— AProgrammer
fonte

10

Prima di tutto, considera cosa accadrebbe se avessimo un rilevatore di arresto. Dall'argomentazione diagonale sappiamo che esiste almeno un programma che potrebbe impedire a un rilevatore di arresto di non arrestarsi o dare una risposta errata. Ma questo è un programma bizzarro e improbabile.

C'è un altro argomento, tuttavia, secondo cui un rilevatore di arresto è impossibile, e questo è l'argomento più intuitivo che un rilevatore di arresto sarebbe magico. Supponiamo di voler sapere se l'ultimo teorema di Fermat è vero o falso. Basta scrivere un programma che si interrompe se è vero e funziona per sempre se è falso, quindi eseguire il rilevatore di arresto su di esso. Non esegui il programma , esegui solo il rilevatore di arresto sul programma . Un rilevatore di arresto ci consentirebbe di risolvere immediatamente un numero enorme di problemi aperti nella teoria dei numeri semplicemente scrivendo programmi.

Quindi, puoi scrivere un linguaggio di programmazione che garantisca la produzione di programmi il cui arresto può essere sempre determinato? Sicuro. Non può avere loop, condizioni e usare arbitrariamente molta memoria. Se sei disposto a vivere senza loop, senza istruzioni "if" o con una quantità di spazio strettamente limitata, allora puoi scrivere una lingua il cui arresto è sempre determinabile.

— Eric Lippert
fonte

2

Si può avere l'istruzione if se il salto deve essere sempre in avanti, mai all'indietro. Sto pensando a un sottoinsieme limitato del linguaggio BASIC, in cui "GOTO X" significa andare al numero di riga currentLine + X e X deve essere maggiore di 0. Se la linea non è valida, fermarsi. Ciò aumenterebbe le esigenze di archiviazione, ma consentirebbe una logica non banale. Questo probabilmente equivale a una macchina a stati finiti in cui i vertici formano un grafico e quel grafico potrebbe non avere alcun ciclo, altrimenti l'FSM non è valido. Inoltre, ogni stato che è un vicolo cieco deve essere uno stato accettante.

— Giobbe

3

potrebbe avere dei loop limitati - per i = da 1 a 10, ad esempio, anche iteratori ben educati. Quindi esiste una classe di problemi finiti che possono essere risolti: il teorema di fermat è di nuovo coinvolto nella sequenza infinita di reali. Ma se limitiamo il dominio a numeri inferiori a 1 000 000, allora si ferma.

— daven11,

2

Perché non le condizioni? Sembra che si possa dimostrare che le condizioni senza salti si fermano sempre ...

— Billy ONeal,

2

@nikie: certo che è un argomento debole. Il punto è che un tale rilevatore di arresto sarebbe in grado di provare o confutare tali dichiarazioni senza necessariamente trovare la prova . L'intuizione che intendo sviluppare qui è che un linguaggio per cui un banale rilevatore di arresto potrebbe essere scritto è un linguaggio che non può rappresentare anche semplici problemi nella teoria dei numeri come l'ultimo teorema di Fermat o congettura di Goldbach, e quindi probabilmente non lo è un linguaggio molto utile.

— Eric Lippert,

3

@EricLippert: Wrong. Un tale linguaggio avrà loop, una corretta memorizzazione e molte altre cose utili. È possibile codificare quasi tutto. Ecco, eccolo: coq.inria.fr

— SK-logic,

6

Ti consiglio di leggere Gödel, Escher, Bach . È un libro molto divertente e illuminante che, tra le altre cose, tocca il teorema di incompletezza di Gödel e il problema dell'arresto.

Per rispondere alla tua domanda in breve: il problema dell'arresto è decidibile purché il tuo programma non contenga un whileciclo (o nessuna delle sue molte possibili manifestazioni).

— zvrba
fonte

Scusa, ti ho letto male. Ho eliminato il mio commento ma riaffermerò la raccomandazione di GEB.

— AProgrammer

@zvrba È stato nella mia lista di lettura per un po 'di tempo - probabilmente è il momento di immergermi.

— Daven11

5

Per ogni programma che funziona con una quantità limitata di memoria (inclusa la memorizzazione di tutti i tipi), il problema di arresto può essere risolto; vale a dire che un programma indecidibile è destinato a richiedere sempre più memoria durante l'esecuzione.

Ma anche così, questa intuizione non significa che può essere utilizzata per problemi del mondo reale, dal momento che un programma di arresto, lavorando su pochi kilobyte di memoria, può facilmente impiegare più tempo della vita residua dell'universo a fermarsi.

— user281377
fonte

3

Per rispondere (parzialmente) alla tua domanda "Esiste un sottoinsieme di programmi che evita il problema dell'arresto": sì, in effetti c'è. Tuttavia, questo sottoinsieme è incredibilmente inutile (si noti che il sottoinsieme di cui sto parlando è un sottoinsieme rigoroso dei programmi che si arrestano).

Lo studio della complessità dei problemi per "la maggior parte degli input" è chiamato complessità dei casi generici . Definisci alcuni sottoinsiemi dei possibili input, provi che questo sottoinsieme copre "la maggior parte degli input" e dai un algoritmo che risolve il problema per questo sottoinsieme.

Ad esempio, il problema dell'arresto è risolvibile in tempo polinomiale per la maggior parte degli input (in effetti, in tempo lineare, se capisco correttamente la carta ).

Tuttavia, questo risultato è piuttosto inutile a causa di tre note a margine: in primo luogo, parliamo di macchine Turing con un singolo nastro, piuttosto che programmi per computer reali su computer reali. Per quanto ne so, nessuno sa se lo stesso vale per i computer del mondo reale (anche se i computer del mondo reale potrebbero essere in grado di calcolare le stesse funzioni delle macchine Turing, il numero di programmi consentiti, la loro durata e se si fermano potrebbero essere completamente differente).

In secondo luogo, devi fare attenzione al significato di "maggior parte degli input". Significa che la probabilità che un programma casuale di 'lunghezza' n possa essere controllato da questo algoritmo tende a 1 come n tende all'infinito. In altre parole, se n è abbastanza grande, allora un programma casuale di lunghezza n può quasi sicuramente essere controllato da questo algoritmo.

Quali programmi possono essere controllati con l'approccio descritto nel documento? In sostanza, tutti i programmi che si arrestano prima di ripetere uno stato (dove "stato" corrisponde approssimativamente a una riga di codice in un programma).

Anche se quasi tutti i programmi possono essere controllati in questo modo, nessuno dei programmi che possono essere controllati in questo modo è molto interessante e di solito non sarà progettato dagli umani, quindi questo non ha alcun valore pratico.

Indica anche che la complessità dei casi generici probabilmente non sarà in grado di aiutarci a risolvere il problema, poiché quasi tutti i programmi interessanti sono (apparentemente) difficili da controllare. Oppure, in altre parole: quasi tutti i programmi sono poco interessanti, ma facili da controllare.

— Alex ten Brink
fonte

2

-1, Questo è sbagliato su così tanti livelli ...

— user281377

1

In primo luogo, i computer del mondo reale non possono calcolare nulla che una macchina di Turing non possa fare. Fino ad ora, nessuno ha mostrato un computer del mondo reale più capace (in termini di calcolabilità) di una macchina Turing. In secondo luogo, se un programma ripete il suo stato, non si arresterà, quindi il problema di interruzione viene risolto per quel programma e input. Ricorda: il problema di arresto riguarda la decisione se un programma si fermerà o meno su un dato input. Un ciclo infinito va bene quando lo rilevi positivamente. Infine: esiste una vasta gamma di programmi utili per i quali il problema dell'arresto è risolvibile: quelli che operano su memoria limitata.

— user281377

Per quanto riguarda il tuo primo numero: come osservato nel documento, mostrare che alcuni modelli di calcolo sono Turing completi non preserva quanti programmi si fermano esattamente, quindi il risultato che dimostrano non significa immediatamente nulla per altri modelli di calcolo. Sono ben consapevole della completezza di Turing e non sono completamente sicuro del perché la mia risposta sia "sbagliata".

— Alex ten Brink,

Per quanto riguarda il tuo secondo problema: gli stati di cui sto parlando non sono gli stessi dello "stato di una macchina" di cui si parla di solito (che coinvolge lo stato di tutto ciò che può avere uno stato), ma piuttosto lo stato dell'automa a stati finiti utilizzato per controllare la macchina di Turing, che corrisponde approssimativamente alla riga di codice su cui un programma sta lavorando in qualsiasi momento durante l'esecuzione. Ripetendo una riga di codice, il contenuto della memoria potrebbe essere diverso, quindi ciò non implica immediatamente l'arresto. Aggiornerò la mia risposta per renderlo più chiaro.

— Alex ten Brink,

@ammoQ: No, il problema dell'arresto non è risolvibile se si parla di sistemi del mondo reale con memoria limitata, poiché ciò significherebbe costruire un sistema del mondo reale in grado di gestire combinazioni di stati. Poiché il numero di possibili stati del registro nella maggior parte delle CPU supera il numero di atomi nell'Universo, non sarai in grado di farlo.

— David Thornley,

3

Esistono, e in effetti ci sono programmi nella vita reale che risolvono continuamente il problema dell'arresto per altri problemi. Fanno parte del sistema operativo su cui stai eseguendo il tuo computer. L'indecidibilità è un'affermazione strana che dice solo che non esiste un programma simile che funzioni per TUTTI gli altri programmi.

Una persona ha giustamente affermato che la prova fermante sembra essere l'unico programma per il quale non può essere risolto, poiché si rintraccia all'infinito come uno specchio. Questa stessa persona ha anche affermato che se ci fosse una macchina di arresto, sarebbe magico perché ci direbbe problemi di matematica difficili dicendoci in anticipo se il suo algoritmo di risoluzione si fermerebbe.

L'ipotesi in entrambi questi casi è che la macchina fermatrice non si rintracci perché non ci sono prove che la traccia. Tuttavia, in realtà effettivamente traccia / esegue il programma su cui viene eseguito con l'input fornito.

La prova logica almeno è semplice. Se non fosse necessario tracciare almeno il primo passaggio, non avrebbe bisogno dell'input insieme al programma su cui è in esecuzione. Per poter utilizzare qualsiasi informazione, deve almeno tracciare il primo passo prima di provare ad analizzare dove sta andando quel percorso.

I difficili problemi matematici menzionati nella risposta in alto sono quelli in cui non è possibile avanzare rapidamente per capire la risposta, il che significa che il problema di interruzione dovrebbe continuare a tracciare fino a quando un certo schema non fosse riconoscibile.

Quindi l'unico argomento pratico da trarre dal problema di arresto è che una macchina di arresto non è in grado di determinare l'esito di un risolutore di problemi ottimizzato più velocemente di quanto il risolutore di problemi possa finire.

Dare una prova formale per questo ragionamento è più difficile e, anche se credo di poterlo fare, tentare di spiegarlo a chiunque un'accademia si tradurrà in loro a lanciare una scimmia come un capriccio e oscillare dal lampadario. È meglio non discutere con quelle persone.

— Terrence Kwasha
fonte

1

ecco la risposta, sì, nel lontano 1967 da http://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf

Che il problema dell'arresto possa almeno essere teoricamente risolto per i sistemi a stati finiti è già stato sostenuto da Minsky nel 1967 [4]: “... qualsiasi macchina a stati finiti, se lasciata completamente a se stessa, finirà per cadere in un periodico perfettamente periodico modello ripetitivo. La durata di questo schema ripetuto non può superare il numero di stati interni della macchina ... "

(e quindi se ti attacchi a macchine da turismo finite, puoi costruire un oracolo)

Naturalmente quanto tempo ci vuole è un'altra domanda

— daven11
fonte

0

c'è un sottoinsieme di programmi che può essere determinato se si fermano?

Sì.

È abbastanza buono per la maggior parte dei programmi?

Definisci "più".

Posso costruire un insieme di costrutti linguistici che posso determinare l '"haltability" di un programma?

Sì.

c'è qualcosa di quasi turing completo che è abbastanza buono?

Definisci "quasi".

Molte persone scrivono Python senza usare whileistruzioni o ricorsioni.

Molte persone scrivono Java usando solo la fordichiarazione con semplici iteratori o contatori che possono essere banalmente dimostrati terminare; e scrivono senza ricorsione.

È abbastanza facile da evitare whilee ricorsivo.

Per un determinato programma in cui tutti gli ingressi sono limitati, è possibile determinare se il programma si interrompe?

No.

In tal caso, quali sono i vincoli della lingua e quali sono i limiti del set di input.

Um. Il problema di Halting significa che il programma non è mai in grado di determinare cose su programmi così complessi come se stesso. È possibile aggiungere uno qualsiasi di un gran numero di vincoli per superare il problema di arresto.

L'approccio standard al problema dell'arresto è quello di consentire alle prove di utilizzare un insieme leggermente più "ricco" di formalismi matematici rispetto a quelli disponibili nel linguaggio di programmazione.

È più semplice estendere il sistema di prova che limitare la lingua. Qualsiasi restrizione porta ad argomenti per l'unico algoritmo che è difficile da esprimere a causa della restrizione.

L'insieme massimo di questi costrutti determinerebbe un linguaggio che può essere dedotto per fermarsi o meno. C'è stato qualche studio su questo?

Sì. Si chiama "Teoria dei gruppi". Un insieme di valori chiuso in un insieme di operazioni. Roba abbastanza ben compresa.

— S. Lott
fonte

"quasi" è il pezzo che sto chiedendo. Esistono problemi finiti per i quali si può dire che un programma si interrompe e quanto è limitato il problema? Ad esempio l'istruzione if (i <10) quindi print (i) si interrompe per tutti i. Se restringo il dominio di i a numeri interi a 32 bit, anche questo si ferma.

— daven11,

Tieni presente che un forciclo è un ciclo while e le persone spesso mettono le cose più complicate nel termine condizione rispetto al semplice x < 42.

— Billy ONeal,

@BillyONeal: buon punto. In Python un forloop è molto, molto strettamente vincolato a funzionare attraverso un iteratore. Un forciclo più generale in Java, tuttavia, può includere condizioni extra che invalidano il semplice utilizzo di un iteratore.

— S.Lott

"Esistono problemi finiti per i quali si può dire che un programma si interrompe?" La risposta rimane sì. "quanto è limitato il problema?" Um. Il finito è finito. Se smetti di provare ad approssimare i numeri reali e ti attieni ai numeri naturali, chiusi sotto tutte le operazioni matematiche, stai facendo una teoria dei gruppi ordinaria. Aritmetica modulare. Niente di speciale. Non è chiaro cosa stai chiedendo. Stai chiedendo cos'è l'aritmetica modulare?

— S.Lott

@ S. Lotto Intendo numeri rappresentati in una macchina, non numeri in senso astratto. Quindi pensa ai numeri come a un numero fisso di bit. Questi numeri hanno regole leggermente diverse da numeri interi e reali. Spero che abbia un senso.

— daven11,