Perché non prendere la rappresentazione unaria dei numeri negli algoritmi numerici?

Un algoritmo di tempo pseudo-polinomiale è un algoritmo che ha tempo di esecuzione polinomiale sul valore di input (magnitudine) ma tempo di esecuzione esponenziale sulla dimensione di input (numero di bit).

Ad esempio, per verificare se un numero è primo o no, richiede un ciclo tra i numeri da 2 a e verificare se mod è zero o meno. Se la mod impiega il tempo O (1), la complessità temporale complessiva sarà O (n).$n$$n-1$$n$ $i$

Ma se lasciamo che sia il numero di bit richiesti per scrivere l'input, allora (binario) quindi e il tempo di esecuzione del problema sarà O ( ) che è esponenziale.$x$$x = \log n$$n = 2^x$$2^x$

La mia domanda è, se consideriamo la rappresentazione unaria dell'input , allora sempre e quindi il tempo pseudo-polinomiale sarà uguale alla complessità del tempo polinomiale. Quindi perché non lo facciamo mai?$n$$x=n$

Inoltre, poiché esiste un algoritmo di tempo pseudo-polinomiale per lo zaino, prendendo , lo zaino sarà polinomiale come risultato P = NP$x=n$

Ciò significa che lo zaino unario è in P. Non significa che lo zaino (con numeri con codifica binaria) sia in P.

Lo zaino è noto per essere NP-completo. Se mostrassi che lo zaino è in P, ciò mostrerebbe che P = NP.

Ma non hai dimostrato che lo zaino è in P. Hai dimostrato che lo zaino unario è in P. Tuttavia, lo zaino unario non è noto per essere NP-completo (in effetti, il sospetto standard è che molto probabilmente non è NP-completo ). Pertanto, mettere uno zaino unario in P non implica che P = NP.

Quindi quale problema dovremmo preoccuparci di più, zaino o zaino unario? Se la tua motivazione si basa su preoccupazioni pratiche, la risposta dipenderà dalla dimensione dei numeri per cui vuoi risolvere il problema dello zaino: se sono grandi, allora ti preoccupi più dello zaino che dello zaino unario. Se la tua motivazione si basa su preoccupazioni teoriche, allora lo zaino è probabilmente più interessante, perché ci consente di ottenere una comprensione più profonda - ci permette di fare una distinzione tra dimensione e grandezza - mentre lo zaino unario ci impedisce di fare tale distinzione.

Per rispondere alla domanda di follow-up sull'algoritmo di programmazione dinamica per il problema dello zaino:

Sì, lo stesso algoritmo di programmazione dinamica può essere applicato sia allo zaino che allo zaino unario. Il suo tempo di esecuzione è polinomiale nella grandezza dei numeri, ma esponenziale (non polinomiale) nella lunghezza dei numeri quando codificato in binario. Pertanto, il suo tempo di esecuzione è polinomiale nella lunghezza dell'ingresso quando l'ingresso è codificato in unario ma non è polinomiale nella lunghezza dell'ingresso quando l'ingresso è codificato in binario. È per questo che facciamo prendere in considerazione questo algoritmo di programmazione dinamica per essere un algoritmo polinomiale per lo zaino unario, ma non lo considerano un algoritmo polinomiale per lo zaino (con codifica binaria).

Ricordiamo che diciamo che un algoritmo viene eseguito nel tempo polinomiale se il suo tempo di esecuzione è al massimo un polinomio della lunghezza dell'input, in bit .

Aggiungerei una piccola cosa alla risposta di DW:

Ho visto persone che pensano che, poiché lo zaino unario è in P, quindi possiamo usarlo al posto dello zaino che i migliori algoritmi attuali hanno tempo esponenziale.

Lasciare che l'ingresso sia e k e considerare l'algoritmo di programmazione dinamica per Knapsack e unario zaino. Il tempo di esecuzione per entrambi è O ( n k ) . È lo stesso tempo di esecuzione. Ad esempio, se si dispone di un input, non importa se si utilizza la programmazione dinamica per Zaino unario o la programmazione dinamica per Zaino. Entrambi impiegheranno (approssimativamente) lo stesso tempo per risolvere l'istanza del problema. Teoricamente ovunque tu usi uno puoi usare anche l'altro. Hai solo bisogno di convertire i numeri da unari a binari e viceversa.$W=\{w_1, \ldots, w_n\}$$k$$O(nk)$

Allora, qual è il punto di definire la complessità degli algoritmi rispetto alla dimensione degli input? Perché non indicarli sempre in termini di parametri come ?$O(nk)$

Se ti preoccupi di un problema in isolamento puoi farlo. In realtà è quello che fanno spesso le persone negli algoritmi. La complessità degli algoritmi grafici è spesso espressa in termini di numero vertici e numero di spigoli, non della dimensione della stringa che li codifica.

Ma questo è solo quando abbiamo a che fare con un problema isolato. Non è utile quando abbiamo a che fare con problemi con diversi tipi di input. Per i grafici possiamo parlare del tempo di esecuzione rispetto al numero di vertici e bordi. Per lo zaino possiamo parlare del numero di articoli e delle dimensioni dello zaino. E se volessimo parlare di entrambi? Ad esempio quando vogliamo riduzioni tra i problemi o discutiamo di una classe di problemi che include problemi arbitrari, non solo quelli con un grafico come input. Abbiamo bisogno di un parametro universale di input. Un input in generale è solo una stringa, siamo noi che interpretiamo i suoi simboli come numeri unari, numeri binari, grafici, ecc. Per sviluppare una teoria generale della complessità dell'algoritmo e dei problemi abbiamo bisogno di un parametro generale degli input. La dimensione dell'input è una scelta ovvia e risulta essere abbastanza robusta da poter costruire una teoria ragionevole su di essa. Non è l'unica possibilità. Per uno artificiale possiamo costruire una teoria basata su$2$

$k$$100$$100$$k$$2^{100}-1$$k$$k$$2^{100}-1$

$n$$n$$p(n)$$k$$p(n)$$k$$2^{p(n)}-1$$k$$k$

$n$$k$

In breve e semplice, ti mostrerò perché.

$Tally$

x = input integer

factors = [];

for i in range(1, x + 1):
    if x % i == 0:
     factors.append(i)

 print(factors)

$x$$x$$O(2^n)$

$Tally/Unary$$O(n)$$x$

x = input tallies

factors = [];

for i in range(1, x + 1):
    if x % i == 0:
     factors.append(i)

 print(factors)

La rappresentazione di input non rende il codice più veloce. Anche se il 2 ° algoritmo è veramente poli-tempo. Non è molto pratico nel trovare i fattori per RSA.