Le funzioni con una crescita più lenta di Ackermann inversa appaiono nei limiti di runtime?

Alcuni algoritmi complicati ( union-find ) hanno la funzione di Ackermann inversa quasi costante che appare nella complessità del tempo asintotico e sono ottimali nel caso peggiore se il termine di Ackermann inverso quasi costante viene ignorato.

Esistono esempi di algoritmi noti con tempi di esecuzione che coinvolgono funzioni che crescono sostanzialmente più lentamente di Ackermann inverso (ad es. Inversioni di funzioni che non sono equivalenti ad Ackermann in trasformazioni polinomiali o esponenziali, ecc.) Che danno il tempo più noto nel caso peggiore complessità per risolvere il problema di fondo?

— user2566092
fonte

algoritmi temporali? Stai chiedendo un problema noto il cui algoritmo più noto è

? Per prima cosa devi trovare una funzione che cresce "fondamentalmente più veloce" di

, come TREE

, quindi prendere il suo inverso, e quindi trovare un problema che si adatta a esso!

O (1)

$O(1)$

ω (1)

$\omega(1)$

o (α (n))

$o(\alpha(n))$

A (n)

$A(n)$

(n)

$(n)$

— Pål GD,

ci sono algoritmi artificiosi arbitrari costruiti dalla gerarchia temporale thm

— vzn

@vzn: Qualsiasi

non è costruibile nel tempo (che include

). Quindi il teorema della gerarchia temporale non può essere usato qui.

f (n) = o (n)

$f(n) = o(n)$

α (n)

$\alpha(n)$

— mdxn,

@mdx sono contento che qualcuno lo abbia fatto notare, solo testandoti l'occhiolino. sì ultimamente avete pensato ci potrebbe essere una generalizzazione di tempo gerarchia THM per sub

funzioni. ma comunque il limite

è dovuto al fatto che una TM costruibile nel tempo deve leggere tutti gli input, ma stiamo dicendo che questi altri algoritmi, ad es. con la complessità temporale inversa di Ackermann, no? avendo problemi a visualizzarlo! sentire la questione è più circa l'esistenza di sub

lingue .... ci potrebbe essere una sorta di sondaggio o la descrizione da qualche parte ....

o (n)

$o(n)$

o (n)

$o(n)$

o (n)

$o(n)$

— VZN

@vzn: L'OP deve davvero chiarire quale modello di calcolo hanno in mente.

devono essere definiti su TM ad accesso casuale (o equivalenti). Quando specifichiamo la nostra meccanica, potremmo inavvertitamente aggiungere troppa potenza. Può anche essere nella misura in cui la nozione di complessità computazionale non è fruttuosa. In termini più elementari, dovremmo cambiare la nostra nozione di complessità temporale (che è ciò che fa il runtime ammortizzato) con il rischio che tale definizione possa diventare molto elaborata (lo stesso vale per il modello di calcolo).

DLOGTIME

$\text{DLOGTIME}$

LH

$\text{LH}$

— mdxn,

Risposte:

Seth Pettie ha escogitato un algoritmo per calcolare la sensibilità di un minimo spanning tree nel tempo , migliorando su un algoritmo di Tarjan che calcola lo stesso nel tempo . (Confronta questo con l' algoritmo di Chazelle per calcolare l'albero di spanning minimo $O(m\log \alpha(m,n))$ $O(m\alpha(m,n))$ $O(m\alpha(m,n))$ stesso.) Il problema della sensibilità richiede di calcolare, per un dato grafico e un determinato albero di spanning minimo, di quanto ogni peso del bordo può cambiare senza cambiare l'albero di spanning minimo.

(Grazie a Tsvi Kopelowitz per questo riferimento.)

— Yuval Filmus
fonte

Non so se il registro inverso Ackermann sia "fondamentalmente più lento" rispetto al contrario, ma ho trovato sorprendente questo tipo di tempo di esecuzione.

— Yuval Filmus,

$\alpha^*(n)$ $n$

— templatetypedef
fonte

-1

Quando Alan Turing ha scoperto il computer, c'erano diversi modelli per il computer proposto. Turing ha dimostrato che alcuni (3) di questi modelli potevano simularsi a vicenda E calcolare la funzione Ackermann, mentre gli altri modelli potevano simularsi a vicenda ma non la funzione Ackermann (quindi non potevano simulare il 3). Pertanto, questi 3 modelli (Turing Machine, von Neumann e uno che non conosco), sono stati scelti come architettura per un computer. Ciò non significa che la funzione Ackermann sia il limite del computer, ma suppongo che sia una scienza ardua. Non sono a conoscenza di alcuna funzione calcolabile che cresce più velocemente della funzione Ackermann.

Ora, non penso che ci sia un problema pratico che corrisponda alla tua domanda, ma forse possiamo costruirne uno. Dobbiamo tuttavia porre dei vincoli sull'input. Dato che non possiamo usare O (n), non possiamo controllare l'intero input. In effetti, non possiamo nemmeno controllare la lunghezza dell'input in quanto sarebbe O (log n). Quindi, abbiamo bisogno come primo parametro di una rappresentazione della lunghezza del resto dell'input, ad esempio c tale che Ackermann (c) sia la lunghezza dell'input. Poiché anche questo non è adatto, chiediamo come primo valore nel nostro input il parametro c, in modo che bb (c) sia circa la lunghezza dell'ingresso, dove bb è la funzione di castoro occupato. Questa funzione è incomutabile ma bb (c) esiste sicuramente. Quindi, l'algoritmo procede come:

for (int i=0; i<c; i++) {
    if (input[i] == null) {
        return false;
    }
}
return true;

Lo scopo dell'algoritmo è verificare che se c è l'inverso di bb, se quindi la lunghezza di input è maggiore di bb (c).

Se esiste una funzione calcolabile che cresce più velocemente della funzione Ackermann, penso che possiamo usarla al contrario per creare un algoritmo che risponda alla tua domanda su qualsiasi input.

— Albert Hendriks
fonte

Esistono sicuramente funzioni che crescono più velocemente della funzione di Ackermann, come sottolineato nei commenti (TREE (n)). La parte difficile della domanda è costruire un algoritmo con un limite di runtime dell'inverso di quella funzione. Una macchina del genere non ha abbastanza tempo per calcolare l'inverso della funzione in primo luogo, quindi la costruzione di una TM che raggiunge questo non è semplice.

— mdxn,