In che misura un algoritmo può prevedere la complessità temporale di un programma di input arbitrario?

Il problema di Halting afferma che è impossibile scrivere un programma in grado di determinare se un altro programma si arresta, per tutti i possibili programmi di input .

Tuttavia, posso sicuramente scrivere un programma in grado di calcolare il tempo di esecuzione di un programma simile a:

for(i=0; i<N; i++)
    { x = 1; }

e restituisce una complessità temporale di , senza mai eseguirla. $N$

Per tutti gli altri programmi di input, restituirebbe un flag indicante che non era in grado di determinare la complessità temporale.

La mia domanda è questa:

Quali condizioni devono rispettare, in modo che possiamo determinare algoritmicamente la complessità temporale di un determinato programma?

* Se c'è un riferimento canonico o un articolo di revisione a questo apprezzerei un link ad esso nei commenti.

— Agganciata
fonte

(1) "La notazione O" non significa "complessità temporale". (2) Non è chiaro cosa intendi con "O (infinito)". Se possibile, evita di inventare una nuova notazione. (3) Decidere se un determinato programma si interrompe o meno e dare un limite superiore esplicito alla complessità temporale del programma è diverso.

— Tsuyoshi Ito,

Non ho familiarità con la deduzione della complessità temporale dei programmi in classi ristrette, ma una classe di programmi che vale la pena verificare è chiamata "programmi a ciclo limitato", per cui è facile limitare la complessità temporale. Ricordo che i programmi a ciclo limitato sono discussi nel capitolo 3 di Gems of Theoretical Computer Science di Uwe Schöning e Randall J. Pruim nel contesto della decisione sull'equivalenza di due programmi, ma non sono sicuro di quanto sia rilevante il capitolo per la tua domanda.

— Tsuyoshi Ito,

Sono un po 'confuso. In che modo è fuori portata? Una risposta ragionevole alla domanda del PO sarebbero i frammenti di linguaggio (o persino le classi di frammenti) per i quali il tempo di esecuzione può essere determinato algoritmicamente.

— Suresh Venkat,

Domanda correlata: i limiti di runtime in P sono decidibili?

— Artem Kaznatcheev

Sono terribilmente in ritardo per questa discussione. Sembriamo balzare nel momento in cui un post profuma di newbie-ish. Non sto puntando le dita. Sento questo istinto da solo. Forse dovremmo essere più gentili. Il PO ha ammesso di non avere familiarità con l'area o i termini. Qual è il punto di un sito di domande e risposte se tolleriamo solo persone che sanno esattamente cosa vogliono e lo chiediamo nella nostra lingua.

— Vijay D,

Risposte:

$T$ $p_T$

input: n
run T for n steps
if T is in halting state, output: 0
otherwise, loop for n^2 steps and output: 0

$p_T$

Tuttavia, è stato svolto molto lavoro sull'effettivo calcolo della complessità del programma. Ho una particolare predilezione per la teoria della complessità implicita che mira a creare linguaggi che, usando costrutti speciali o discipline di tipo, permettano di scrivere solo programmi che abitano in una certa classe di complessità ben definita. Da quello che considero un miracolo, queste lingue sono spesso complete per quella classe!

Un esempio particolarmente interessante è descritto in questo articolo di J.-Y. Marion, che descrive un piccolo linguaggio imperativo, con una disciplina di tipo ispirato dalle tecniche di informazione-flow e analisi di sicurezza, che consente una caratterizzazione di algoritmi in P .

— cody
fonte

Come nota a margine, vedi anche Epigram, che è una lingua che può garantire la risoluzione.

— Realz Slaw,

Questo è un buon inizio, ma c'è altro da dire? (Ad esempio, mi sembra che il tempo di esecuzione di una determinata funzione ricorsiva elementare debba essere semplice da calcolare, tuttavia tali funzioni possono risolvere qualsiasi problema nella gerarchia esponenziale ....)

— usul

Nella misura in cui è possibile determinare che il programma di input è scritto in una lingua limitata, si può presumere che la complessità temporale sia limitata da qualsiasi limite superiore imposto dalla lingua. Tuttavia, molte funzioni ricorsive primitive hanno equivalenti ricorsivi generali che sono più efficienti

— Chris Pressey,

(accidentalmente salvato quel commento in anticipo, quindi superato il limite di 5 minuti. La seconda frase dovrebbe essere la seguente: :) Tuttavia, i programmi in queste lingue con restrizioni possono avere equivalenti in lingue con meno restrizioni che sono più efficienti (nello specifico, molte funzioni ricorsive primitive hanno equivalenti ricorsivi generali che sono più efficienti) che, in pratica, incoraggia l'uso di linguaggi senza restrizioni, più difficili da analizzare.

— Chris Pressey,

È molto interessante Chris! Hai un riferimento? In effetti sembra contro-inutile: avrei sospettato che funzioni ricorsive primitive potessero simulare funzioni ricorsive generali per un dato numero di passi, il che limiterebbe quindi l'accelerazione a un fattore costante.

— cody,

La domanda che poni e il trucco conteggio specifico che descrivi è classico nell'analisi del programma. C'è il problema teorico dell'analisi della complessità, ed è una manifestazione pratica in termini di stima automatica delle prestazioni di un pezzo di codice. Un'analisi così automatizzata ha diverse applicazioni dal rilevamento dei bug delle prestazioni alla stima del costo per alcuni calcoli nel cloud.

Cody ha sottolineato che il problema è indecidibile in generale. Questo problema è più difficile che provare la risoluzione, perché ottenere un limite di complessità comporta anche la chiusura del programma. Esistono due approcci a tale problema. Uno proviene dall'analisi del programma. L'idea di aggiungere un contatore e stimarne il valore esiste dagli anni '70. Questa codifica riduce il problema di determinare il tempo di esecuzione a quello del calcolo di un invariante.

Un secondo approccio è progettare un linguaggio di programmazione che ammetta solo programmi di una certa complessità limitata. Questa è l'area della complessità computazionale implicita.

Seguono alcuni riferimenti per entrambe le aree.

Il progetto SPEED è una linea specifica di lavoro di analisi del programma che si concentra su come trovare limiti sui contatori una volta introdotti nel programma. I contatori possono misurare il tempo o il consumo di spazio.
Analisi delle risorse ammortizzate multivariate , Jan Hoffman, Klaus Aehlig, Martin Hoffman, ACM TOPLAS 2012
Sulle proprietà decise del tasso di crescita dei programmi imperativi , Amir Ben Amram, sviluppi nella conformità computazionale implicita 2010. Questa è una bellissima linea di lavoro sulla limitazione della complessità dei programmi imperativi mediante restrizioni sintattiche.

— Vijay D
fonte