Por que não usar a representação unária de números em algoritmos numéricos?

Um algoritmo de tempo pseudo-polinomial é um algoritmo que possui tempo de execução polinomial no valor de entrada (magnitude), mas tempo de execução exponencial no tamanho da entrada (número de bits).

Por exemplo, testando se um número é primo ou não, requer um loop através de números de 2 a n - 1 e verifique se n mod i é zero ou não. Se o mod demorar O (1), a complexidade geral do tempo será O (n).$n$$n-1$$n$ $i$

Mas se deixarmos ser o número de bits necessários para gravar a entrada, x = log n (binário), então n = 2 x, e o tempo de execução do problema será O ( 2 $x$$x = \log n$$n = 2^x$$2^x$ ), que é exponencial.

Minha pergunta é, se considerarmos a representação unária da entrada , sempre x = $n$$x=n$ tempo pseudo-polinomial será igual à complexidade do tempo polinomial. Então, por que nunca fazemos isso?

Além disso, como existe um algoritmo de tempo pseudo-polinomial para a mochila, tomando , a mochila será polinomial como resultado P = NP$x=n$

O que isto significa é que a mochila unária está em P. Isso não significa que a mochila (com números codificados em binário) está em P.

Sabe-se que a mochila é NP-completa. Se você mostrasse que a mochila está em P, isso mostraria que P = NP.

Mas você não mostrou que a mochila está em P. Você mostrou que a mochila unária está em P. No entanto, a mochila unária não é conhecida por ser NP-completa (na verdade, a suspeita padrão é que ela provavelmente não é NP-completa ) Portanto, colocar mochila unária em P não implica que P = NP.

Então, com qual problema devemos nos preocupar mais, mochila ou mochila unária? Se sua motivação é baseada em preocupações práticas, a resposta dependerá do tamanho dos números para os quais você deseja resolver o problema da mochila: se eles forem grandes, certamente você se preocupa mais com a mochila do que com a mochila unária. Se sua motivação é baseada em preocupações teóricas, a mochila é sem dúvida mais interessante, porque nos permite uma compreensão mais profunda - nos permite fazer a distinção entre tamanho e magnitude - enquanto a mochila unária nos impede de fazer essa distinção.

Para responder à pergunta de acompanhamento sobre o algoritmo de programação dinâmica para o problema da mochila:

Sim, o mesmo algoritmo de programação dinâmica pode ser aplicado às mochilas e à mochila unária. Seu tempo de execução é polinomial na magnitude dos números, mas exponencial (não polinomial) no comprimento dos números quando codificado em binário. Assim, seu tempo de execução é polinomial no comprimento da entrada quando a entrada é codificada em unária, mas não é polinomial no comprimento da entrada quando a entrada é codificada em binário. É por isso que consideramos esse algoritmo de programação dinâmica um algoritmo de tempo polinomial para mochila unária, mas não consideramos que seja um algoritmo de tempo polinomial para mochila (codificada em binário).

Lembre-se de que dizemos que um algoritmo é executado em tempo polinomial se seu tempo de execução é no máximo algum polinômio do comprimento da entrada, em bits .

Eu acrescentaria uma pequena coisa à resposta da DW:

Vi pessoas que pensam que, porque o Knapsack unário está em P, portanto, podemos usá-lo no lugar do Knapsack, que melhores algoritmos atuais têm tempo exponencial.

$W=\{w_1, \ldots, w_n\}$$k$$O(nk)$

$O(nk)$

Se você se importa com um problema isolado, pode fazê-lo. Na verdade, é isso que as pessoas nos algoritmos costumam fazer. A complexidade dos algoritmos de gráfico é frequentemente expressa em termos dos vértices numéricos e do número de arestas, não do tamanho da string que os codifica.

Mas isso é apenas quando estamos lidando com um problema isolado. Não é útil quando estamos lidando com problemas com diferentes tipos de entradas. Para gráficos, podemos falar sobre o tempo de execução por número de vértices e arestas. Para a mochila, podemos falar sobre o número de itens e o tamanho da mochila. Mas e se queremos conversar sobre os dois? Por exemplo, quando queremos reduções entre problemas ou discutimos classes de problemas que incluem problemas arbitrários, não apenas aqueles com um gráfico como entrada. Precisamos de um parâmetro universal de entradas. Uma entrada em geral é apenas uma cadeia, somos nós que interpretamos seus símbolos como números unários, números binários, gráficos etc. Para desenvolver uma teoria geral da complexidade do algoritmo e dos problemas, precisamos de um parâmetro geral de entradas. O tamanho da entrada é uma escolha óbvia e acaba sendo robusto o suficiente para que possamos construir uma teoria razoável sobre ela. Não é a única possibilidade. Para um artificial, podemos construir uma teoria baseada em$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$

Em resumo e simples, mostrarei o porquê.

Suponha que você tenha um algoritmo de fatoração. Exceto pela pequena diferença de que um aceita números inteiros para entrada e o outro$Tally$. Como você pode ver, os dois trechos de código são semelhantes.

x = input integer

factors = [];

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

 print(factors)

Observe que o algoritmo acima é polinomial do valor numérico de $x$. Vai levar$x$quantidade de etapas no loop. Mas quando se trata de tamanho de bit, na verdade$O(2^n)$.

Suponha que eu faça uma pequena edição no código que incluirá $Tally/Unary$. Agora será$O(n)$ tempo no valor e no comprimento da entrada $x$.

x = input tallies

factors = [];

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

 print(factors)

A representação de entrada não torna o código mais rápido. Mesmo que o segundo algoritmo seja verdadeiramente poli-tempo. Não é muito prático encontrar os fatores para a RSA.