Stavo cercando di spiegare a qualcuno che C è completo di Turing e mi sono reso conto che in realtà non so se tecnicamente sia completo di Turing. (C come nella semantica astratta, non come in un'implementazione effettiva.)

La risposta "ovvia" (approssimativamente: può indirizzare una quantità arbitraria di memoria, quindi può emulare una macchina RAM, quindi è Turing-complete) non è in realtà corretta, per quanto posso dire, come se lo standard C lo consenta affinché size_t sia arbitrariamente grande, deve essere fissato a una certa lunghezza e, indipendentemente dalla lunghezza a cui è fissato, è ancora finito. (In altre parole, anche se potresti, data una macchina Turing di arresto arbitraria, scegliere una lunghezza di size_t tale che funzionerà "correttamente", non c'è modo di scegliere una lunghezza di size_t tale che tutte le macchine di Turing che si fermano funzionino correttamente)

Quindi: C99 Turing è completo?

Non sono sicuro ma penso che la risposta sia no, per ragioni piuttosto sottili. Ho chiesto a Teorica Informatica alcuni anni fa e non ho avuto una risposta che vada oltre ciò che presenterò qui.

Nella maggior parte dei linguaggi di programmazione, è possibile simulare una macchina Turing:

• simulare l'automa finito con un programma che utilizza una quantità finita di memoria;
• simulando il nastro con una coppia di liste collegate di numeri interi, che rappresentano il contenuto del nastro prima e dopo la posizione corrente. Spostare il puntatore significa trasferire la testa di una delle liste sull'altra lista.

Un'implementazione concreta in esecuzione su un computer esaurirebbe la memoria se il nastro fosse troppo lungo, ma un'implementazione ideale potrebbe eseguire fedelmente il programma della macchina di Turing. Questo può essere fatto con carta e penna, o acquistando un computer con più memoria e un compilatore indirizzato a un'architettura con più bit per parola e così via se il programma esaurisce la memoria.

Questo non funziona in C perché è impossibile avere un elenco collegato che può crescere per sempre: c'è sempre un limite al numero di nodi.

Per spiegare perché, devo prima spiegare cos'è un'implementazione in C. C è in realtà una famiglia di linguaggi di programmazione. Lo standard ISO C (più precisamente, una versione specifica di questo standard) definisce (con il livello di formalità che l'inglese consente) la sintassi e la semantica una famiglia di linguaggi di programmazione. C ha molti comportamenti indefiniti e comportamenti definiti dall'implementazione. Una "implementazione" di C codifica tutto il comportamento definito dall'implementazione (l'elenco delle cose da codificare è nell'appendice J per C99). Ogni implementazione di C è un linguaggio di programmazione separato. Si noti che il significato della parola "implementazione" è un po 'peculiare: ciò che significa in realtà è una variante di lingua, possono esserci più programmi di compilazione diversi che implementano la stessa variante di lingua.

In una data implementazione di C, un byte ha valori possibili. Tutti i dati possono essere rappresentati come una matrice di byte: un tipo ha al massimo possibili valori. Questo numero varia in diverse implementazioni di C, ma per una data implementazione di C, è una costante.$2^{\texttt{CHAR_BIT}}$t$2^{\texttt{CHAR_BIT} \times \texttt{sizeof(t)}}$

In particolare, i puntatori possono assumere al massimo . Ciò significa che esiste un numero massimo finito di oggetti indirizzabili.$2^{\texttt{CHAR_BIT} \times \texttt{sizeof(void*)}}$

I valori di CHAR_BITe sizeof(void*)sono osservabili, quindi se si esaurisce la memoria, non è possibile riprendere a eseguire il programma con valori maggiori per tali parametri. Eseguiresti il ​​programma con un linguaggio di programmazione diverso - un'implementazione C diversa.

Se i programmi in una lingua possono avere solo un numero limitato di stati, il linguaggio di programmazione non è più espressivo degli automi finiti. Il frammento di C che è limitato alla memoria indirizzabile consente al massimo indica dove è la dimensione dell'albero di sintassi astratto della programma (che rappresenta lo stato del flusso di controllo), quindi questo programma può essere simulato da un automa finito con molti stati. Se C è più espressivo, deve essere attraverso l'uso di altre funzionalità.$n \times 2^{\texttt{CHAR_BIT} \times \texttt{sizeof(void*)}}$$n$

C non impone direttamente una profondità massima di ricorsione. Un'implementazione può avere un massimo, ma può anche non averne uno. Ma come possiamo comunicare tra una chiamata di funzione e il suo genitore? Gli argomenti non sono utili se sono indirizzabili, perché ciò limiterebbe indirettamente la profondità della ricorsione: se si dispone di una funzione, int f(int x) { … f(…) …}tutte le occorrenze xsu frame attivi di fhanno il proprio indirizzo e quindi il numero di chiamate nidificate è limitato dal numero di possibili indirizzi per x.

Il programma CA può utilizzare la memorizzazione non indirizzabile sotto forma di registervariabili. Le implementazioni "normali" possono avere solo un numero limitato e limitato di variabili che non hanno un indirizzo, ma in teoria un'implementazione potrebbe consentire una quantità illimitata di registerspazio di archiviazione. In una tale implementazione, è possibile effettuare una quantità illimitata di chiamate ricorsive a una funzione, purché lo siano i suoi argomenti register. Ma dal momento che gli argomenti sono register, non è possibile indicarli e quindi è necessario copiare i loro dati in modo esplicito: è possibile passare solo una quantità finita di dati, non una struttura di dati di dimensioni arbitrarie fatta di puntatori.

Con la profondità di ricorsione illimitata e la restrizione che una funzione può ottenere solo i dati dal suo chiamante diretto ( registerargomenti) e restituire i dati al suo chiamante diretto (il valore di ritorno della funzione), si ottiene la potenza di automi pushdown deterministici .

Non riesco a trovare un modo per andare oltre.

(Naturalmente è possibile fare in modo che il programma memorizzi il contenuto del nastro esternamente, tramite le funzioni di input / output del file. Ma non si chiederà se C è Turing completo, ma se C più un sistema di archiviazione infinito è Turing completo, per che la risposta è un noioso "sì". Si potrebbe anche definire l'archiviazione come un oracolo di Turing - chiamata  fopen("oracle", "r+"), fwriteil contenuto del nastro iniziale e freadindietro il contenuto del nastro finale.)

L'aggiunta di va_copyC99 all'argomento variadico API può darci una via di accesso alla completezza di Turing. Dal momento che diventa possibile scorrere più volte una lista di argomenti variadici in una funzione diversa da quella che ha originariamente ricevuto gli argomenti, va_argspuò essere utilizzato per implementare un puntatore senza puntatore.

Ovviamente, un'implementazione reale dell'argomento dell'API variadica probabilmente avrà un puntatore da qualche parte, ma nella nostra macchina astratta può invece essere implementata usando la magia.

Ecco una demo che implementa un automa pushdown a 2 stack con regole di transizione arbitrarie:

#include <stdarg.h>
typedef struct { va_list va; } wrapped_stack; // Struct wrapper needed if va_list is an array type.
#define NUM_SYMBOLS /* ... */
#define NUM_STATES /* ... */
typedef enum { NOP, POP1, POP2, PUSH1, PUSH2 } operation_type;
typedef struct { int next_state; operation_type optype; int opsymbol; } transition;
transition transition_table[NUM_STATES][NUM_SYMBOLS][NUM_SYMBOLS] = { /* ... */ };

void step(int state, va_list stack1, va_list stack2);
void push1(va_list stack2, int next_state, ...) {
    va_list stack1;
    va_start(stack1, next_state);
    step(next_state, stack1, stack2);
}
void push2(va_list stack1, int next_state, ...) {
    va_list stack2;
    va_start(stack2, next_state);
    step(next_state, stack1, stack2);
}
void step(int state, va_list stack1, va_list stack2) {
    va_list stack1_copy, stack2_copy;
    va_copy(stack1_copy, stack1); va_copy(stack2_copy, stack2);
    int symbol1 = va_arg(stack1_copy, int), symbol2 = va_arg(stack2_copy, int);
    transition tr = transition_table[state][symbol1][symbol2];
    wrapped_stack ws;
    switch(tr.optype) {
        case NOP: step(tr.next_state, stack1, stack2);
        // Note: attempting to pop the stack's bottom value results in undefined behavior.
        case POP1: ws = va_arg(stack1_copy, wrapped_stack); step(tr.next_state, ws.va, stack2);
        case POP2: ws = va_arg(stack2_copy, wrapped_stack); step(tr.next_state, stack1, ws.va);
        case PUSH1: va_copy(ws.va, stack1); push1(stack2, tr.next_state, tr.opsymbol, ws);
        case PUSH2: va_copy(ws.va, stack2); push2(stack1, tr.next_state, tr.opsymbol, ws);
    }
}
void start_helper1(va_list stack1, int dummy, ...) {
    va_list stack2;
    va_start(stack2, dummy);
    step(0, stack1, stack2);
}
void start_helper0(int dummy, ...) {
    va_list stack1;
    va_start(stack1, dummy);
    start_helper1(stack1, 0, 0);
}
// Begin execution in state 0 with each stack initialized to {0}
void start() {
    start_helper0(0, 0);
}

Nota: se va_listè un tipo di array, in realtà ci sono parametri puntatore nascosti nelle funzioni. Quindi sarebbe probabilmente meglio cambiare i tipi di tutti gli va_listargomenti in wrapped_stack.

Aritmetica non standard, forse?

Quindi, sembra che il problema sia la dimensione finita di sizeof(t). Tuttavia, penso di conoscere un lavoro in giro.

Per quanto ne so, C non richiede un'implementazione per usare gli interi standard per il suo tipo intero. Pertanto, potremmo usare un modello aritmetico non standard . Quindi, impostiamo sizeof(t)un numero non standard e ora non lo raggiungeremo mai in un numero finito di passaggi. Pertanto, la lunghezza del nastro delle macchine di Turing sarà sempre inferiore al "massimo", poiché il massimo è letteralmente impossibile da raggiungere. sizeof(t)semplicemente non è un numero nel senso normale della parola.

Questo è un tecnicismo ovviamente: il teorema di Tennenbaum . Afferma che l'unico modello dell'aritmetica di Peano è quello standard, cosa che ovviamente non farebbe. Tuttavia, per quanto ne so, C non richiede implementazioni per utilizzare tipi di dati che soddisfino gli assiomi di Peano, né richiede che l'implementazione sia calcolabile, quindi questo non dovrebbe essere un problema.

Cosa dovrebbe accadere se si tenta di generare un numero intero non standard? Bene, puoi rappresentare qualsiasi numero intero non standard utilizzando una stringa non standard, quindi esegui semplicemente lo streaming di cifre dalla parte anteriore di quella stringa.

IMO, una forte limitazione è che lo spazio indirizzabile (tramite la dimensione del puntatore) è finito, e questo è irrecuperabile.

Si potrebbe sostenere che la memoria può essere "scambiata su disco", ma a un certo punto le informazioni sull'indirizzo supereranno di per sé le dimensioni indirizzabili.

In pratica, queste restrizioni sono irrilevanti per la completezza di Turing. Il vero requisito è consentire al nastro di essere arbitrariamente lungo, non infinito. Ciò creerebbe un problema di arresto di diverso tipo (in che modo l'universo "calcola" il nastro?)

È fasullo come dire "Python non è Turing completo perché non puoi fare una lista infinitamente grande".

[Modifica: grazie a Mr. Whitledge per aver chiarito come modificare.]

I supporti rimovibili ci consentono di aggirare il problema di memoria illimitata. Forse la gente penserà che questo sia un abuso, ma penso che sia OK e comunque inevitabile.

Risolve qualsiasi implementazione di una macchina Turing universale. Per il nastro, utilizziamo supporti rimovibili. Quando la testina termina alla fine o all'inizio del disco corrente, la macchina richiede all'utente di inserire il successivo o il precedente. Possiamo usare un marcatore speciale per indicare l'estremità sinistra del nastro simulato o avere un nastro non legato in entrambe le direzioni.

Il punto chiave qui è che tutto ciò che il programma C deve fare è finito. Il computer ha solo bisogno di memoria sufficiente per simulare l'automa e size_tdeve essere abbastanza grande da consentire di indirizzare quella (in realtà piuttosto piccola) quantità di memoria e sui dischi, che possono avere qualsiasi dimensione finita fissa. Poiché all'utente viene richiesto solo di inserire il disco successivo o precedente, non abbiamo bisogno di numeri interi grandi e illimitati per dire "Inserire il numero del disco 123456 ..."

Suppongo che l'obiezione principale sia probabilmente quella del coinvolgimento dell'utente, ma ciò sembra inevitabile in qualsiasi implementazione, perché non sembra esserci altro modo di implementare la memoria illimitata.

Scegli size_tdi essere infinitamente grande

Puoi scegliere size_tdi essere infinitamente grande. Naturalmente, è impossibile realizzare una tale implementazione. Ma non è una sorpresa, data la natura limitata del mondo in cui viviamo.

Implicazioni pratiche

Ma anche se fosse possibile realizzare tale implementazione, ci sarebbero problemi pratici. Considera la seguente dichiarazione C:

printf("%zu\n",SIZE_MAX);

SIZE_MAXSIZE_MAX$O(2^{size\_t})$size_tSIZE_MAXprintf

Fortunatamente, per i nostri scopi teorici, non ho trovato alcun requisito nella specifica che le garanzie printfterminino per tutti gli input. Quindi, per quanto ne so, non violiamo le specifiche C qui.

Sulla completezza computazionale

Resta ancora da dimostrare che la nostra implementazione teorica è Turing Complete . Possiamo dimostrarlo implementando "qualsiasi Turing Machine a nastro singolo".

Molti di noi hanno probabilmente implementato una Turing Machine come progetto scolastico. Non fornirò i dettagli di un'implementazione specifica, ma ecco una strategia comunemente usata:

• Il numero di stati, il numero di simboli e la tabella di transizione degli stati sono fissi per ogni macchina. Quindi possiamo rappresentare stati e simboli come numeri e la tabella di transizione di stato come un array bidimensionale.
• Il nastro può essere rappresentato come un elenco collegato. Possiamo utilizzare un singolo elenco a doppio collegamento o due elenchi a collegamento singolo (uno per ogni direzione dalla posizione corrente).

Ora vediamo cosa è necessario per realizzare tale implementazione:

• La capacità di rappresentare alcuni insiemi di numeri fissi, ma arbitrariamente grandi. Per rappresentare qualsiasi numero arbitrario, scegliamo MAX_INTdi essere anche infiniti. (In alternativa, potremmo usare altri oggetti per rappresentare stati e simboli.)
• La capacità di costruire un elenco di collegamenti arbitrariamente grande per il nostro nastro. Ancora una volta, non esiste un limite finito per le dimensioni. Ciò significa che non possiamo costruire questo elenco in anticipo, poiché spenderemmo per sempre solo per costruire il nostro nastro. Ma possiamo costruire questo elenco in modo incrementale se utilizziamo l'allocazione dinamica della memoria. Possiamo usare malloc, ma c'è un po 'di più che dobbiamo considerare:
  • La specifica C consente mallocdi fallire se, ad esempio, la memoria disponibile è stata esaurita. Quindi la nostra implementazione è veramente universale se mallocnon fallisce mai.
  • Tuttavia, se la nostra implementazione viene eseguita su una macchina con memoria infinita, non è necessario mallocfallire. Senza violare lo standard C, la nostra implementazione garantirà che mallocnon fallirà mai.
• La capacità di dereferenziare i puntatori, cercare gli elementi dell'array e accedere ai membri di un nodo elenco collegato.

Quindi l'elenco sopra è ciò che è necessario per implementare una Turing Machine nella nostra ipotetica implementazione C. Queste funzionalità devono terminare. Tuttavia, qualsiasi altra cosa può essere autorizzata a non terminare (a meno che non sia richiesto dalla norma). Ciò include l'aritmetica, l'IO, ecc.

L'argomento principale qui era che la dimensione di size_t è finita, sebbene possa essere infinitamente grande.

C'è una soluzione alternativa, anche se non sono sicuro che questo coincida con ISO C.

Supponiamo di avere una macchina con memoria infinita. Quindi non sei limitato per la dimensione del puntatore. Hai ancora il tuo tipo size_t. Se mi chiedi cos'è sizeof (size_t) la risposta sarà solo sizeof (size_t). Se chiedi se è maggiore di 100, ad esempio, la risposta è sì. Se chiedi cos'è sizeof (size_t) / 2 come puoi immaginare, la risposta è ancora sizeof (size_t). Se vuoi stamparlo possiamo concordare un po 'di output. La differenza di questi due può essere NaN e così via.

Il riassunto è che il rilassamento della condizione per size_t ha dimensioni finite non romperà alcun programma già esistente.

PS Allocare la dimensione della memoria (size_t) è ancora possibile, hai solo bisogno di dimensioni numerabili, quindi diciamo che prendi tutti i pari (o un trucco simile).

Sì.

1. Risposta tra virgolette

Come reazione all'elevata quantità di voti negativi sulle mie (e altre) risposte corrette - in confronto all'approvazione allarmante di false risposte - ho cercato una spiegazione alternativa meno teoricamente profonda. Ho trovato questo . Spero che copra alcuni degli errori comuni qui, in modo che venga mostrato un po 'più di intuizione. Parte essenziale dell'argomento:

[...] La sua argomentazione è la seguente: supponiamo che uno abbia scritto un determinato programma di terminazione che potrebbe richiedere, durante la sua esecuzione, fino a una quantità arbitraria di memoria. Senza cambiare quel programma, è possibile a posteriori implementare un componente hardware del computer e il suo compilatore C che forniscono spazio sufficiente per accogliere questo calcolo. Ciò potrebbe richiedere l'ampliamento della larghezza del carattere (tramite CHAR_BITS) e / o dei puntatori (tramite dimensione_t), ma non è necessario modificare il programma. Poiché ciò è possibile, C è davvero Turing-Complete per la chiusura dei programmi.

La parte difficile di questo argomento è che funziona solo quando si considera la conclusione dei programmi. I programmi di terminazione hanno questa bella proprietà che hanno un limite superiore statico al loro requisito di archiviazione, che si può determinare sperimentalmente eseguendo il programma sull'input desiderato con dimensioni di archiviazione crescenti, fino a quando non si adatta.

Il motivo per cui sono stato indotto in errore nel mio treno di pensieri è che stavo considerando la più ampia classe di programmi "utili" non terminanti [...]

In breve, poiché per ogni funzione calcolabile esiste una soluzione nel linguaggio C (a causa di limiti superiori illimitati), ogni problema calcolabile ha un programma C, quindi C è Turing completo.

2. La mia risposta originale

Esistono confusioni diffuse tra concetti matematici nell'informatica teorica (come la completezza di Turing) e la loro applicazione nel mondo reale, vale a dire tecniche nell'informatica pratica. La completezza di Turing non è una proprietà di macchine fisicamente esistenti o di qualsiasi modello limitato nello spazio-tempo. È solo un oggetto astratto che descrive le proprietà delle teorie matematiche.

C99 è Turing completo indipendentemente dalle restrizioni basate sull'implementazione, proprio come praticamente qualsiasi altro linguaggio di programmazione comune, poiché è in grado di esprimere un set funzionalmente completo di connettivi logici e in linea di principio ha accesso a una quantità illimitata di memoria. La gente ha sottolineato che C limita esplicitamente la limitazione dell'accesso alla memoria casuale, ma questo non è nulla che non si possa eludere, dal momento che si tratta di ulteriori restrizioni dichiarate nello standard C, mentre la completezza di Turing è già senza di esse :

Ecco una cosa basilare sui sistemi logici che dovrebbe essere sufficiente per una dimostrazione non costruttiva . Considera un calcolo con alcuni schemi e regole di assioma, in modo tale che l'insieme di conseqenze logiche sia X. Ora se aggiungi alcune regole o assiomi, l'insieme di conseguenze logiche cresce, cioè deve essere un superset di X. Ecco perché, ad esempio , la logica modale S4 è correttamente contenuta in S5. Allo stesso modo, quando si ha una sottospecifica che è Turing completa, ma si aggiungono alcune restrizioni in alto, queste non impediscono nessuna delle conseguenze in X, cioè ci deve essere un modo per aggirare tutte le restrizioni. Se si desidera una lingua non completa di Turing, il calcolo deve essere ridotto, non esteso. Le estensioni che sostengono che qualcosa non sarebbe possibile, ma in realtà lo sono, aggiungono solo incoerenze. Queste incoerenze nello standard C non possono tuttavia avere conseguenze pratiche, proprio come la completezza di Turing non è correlata all'applicazione pratica.

La simulazione di numeri arbitrari in base alla profondità di ricorsione (vale a dire questo ; con la possibilità di supportare più numeri tramite schedulazione / pseudo-thread; non esiste un limite teorico alla profondità di ricorsione in C ) o l'utilizzo dell'archiviazione dei file per simulare memoria di programma illimitata ( idea ) sono probabilmente solo due delle infinite possibilità per provare costruttivamente la completezza di Turing di C99. Bisogna ricordare che per la calcolabilità, la complessità del tempo e dello spazio sono irrilevanti. In particolare, assumere un ambiente limitato per falsificare la completezza di Turing è semplicemente un ragionamento circolare poiché tale limitazione esclude tutti i problemi che superano il presupposto limite di complessità.

( NOTA : ho scritto solo questa risposta per impedire alle persone di essere arrestate per ottenere intuizione matematica a causa di un tipo di pensiero limitato orientato all'applicazione. È un peccato che la maggior parte degli studenti leggerà la risposta falsa accettata a causa del suo voto basato su difetti fondamentali del ragionamento, in modo che più persone diffondano tali false credenze. Se declassate questa risposta, siete solo una parte del problema.)