Pourquoi ne pas prendre la représentation unaire des nombres dans les algorithmes numériques?

Un algorithme de temps pseudo-polynomial est un algorithme qui a un temps d'exécution polynomial sur la valeur d'entrée (amplitude) mais un temps d'exécution exponentiel sur la taille d'entrée (nombre de bits).

Par exemple, tester si un nombre est premier ou non, nécessite une boucle à travers les nombres de 2 à et vérifier si mod est zéro ou non. Si le mod prend du temps O (1), la complexité temporelle globale sera O (n).$n$$n-1$$n$ $i$

Mais si nous laissons être le nombre de bits requis pour écrire l'entrée, alors (binaire) donc et le temps d'exécution du problème sera O ( ) qui est exponentiel.$x$$x = \log n$$n = 2^x$$2^x$

Ma question est, si nous considérons la représentation unaire de l'entrée , alors toujours et le temps pseudo-polynomial sera égal à la complexité temporelle polynomiale. Alors pourquoi on ne fait jamais ça?$n$$x=n$

De plus, comme il existe un algorithme pseudo-polynomial pour le sac à dos, en prenant , le sac à dos sera polynomial en conséquence P = NP$x=n$

Cela signifie que le sac à dos unaire est en P. Cela ne signifie pas que le sac à dos (avec des nombres codés en binaire) est en P.

Le sac à dos est connu pour être NP-complet. Si vous montriez que le sac à dos est en P, cela montrerait que P = NP.

Mais vous n'avez pas montré que le sac à dos est en P. Vous avez montré que le sac à dos unaire est en P. Cependant, le sac à dos unaire n'est pas connu pour être NP-complet (en effet, le soupçon standard est qu'il est très probablement pas NP-complet ). Par conséquent, mettre un sac à dos unaire dans P n'implique pas que P = NP.

Alors, à quel problème devrions-nous nous préoccuper davantage, le sac à dos ou le sac à dos unaire? Si votre motivation est basée sur des préoccupations pratiques, la réponse dépendra de la taille des nombres pour lesquels vous souhaitez résoudre le problème du sac à dos: s'ils sont grands, alors vous vous souciez certainement plus du sac à dos que du sac à dos unaire. Si votre motivation est basée sur des préoccupations théoriques, alors le sac à dos est sans doute plus intéressant, car il nous permet d'avoir une compréhension plus profonde - il nous permet de faire la distinction entre taille et ampleur - tandis que le sac à dos unaire nous empêche de faire cette distinction.

Pour répondre à la question de suivi sur l'algorithme de programmation dynamique pour le problème du sac à dos:

Oui, le même algorithme de programmation dynamique peut être appliqué à la fois aux sacs à dos et au sac à dos unaire. Son temps d'exécution est polynomial dans la magnitude des nombres, mais exponentiel (pas polynomial) dans la longueur des nombres lorsqu'il est codé en binaire. Ainsi, son temps de fonctionnement est polynomial dans la longueur de l'entrée lorsque l'entrée est codée en unaire mais n'est pas polynomial dans la longueur de l'entrée lorsque l'entrée est codée en binaire. Voilà pourquoi nous ne considérons cet algorithme de programmation dynamique pour un algorithme polynomial pour unaire havresac, mais ne le considèrent comme étant un algorithme polynomial pour (codé en binaire) havresac.

Rappelons que nous disons qu'un algorithme s'exécute en temps polynomial si son temps d'exécution est au plus un polynôme de la longueur de l'entrée, en bits .

J'ajouterais une petite chose à la réponse de DW:

J'ai vu des gens qui pensent que parce que Knapsack unaire est en P, nous pouvons donc l'utiliser à la place de Knapsack dont les meilleurs algorithmes actuels ont un temps exponentiel.

Soit l'entrée = et k et considérons l'algorithme de programmation dynamique pour Knapsack et unary Knapsack. Le temps d'exécution pour les deux est O ( n k ) . C'est le même temps d'exécution. C'est-à-dire que si vous avez une entrée, peu importe si vous utilisez la programmation dynamique pour Knapsack unaire ou la programmation dynamique pour Knapsack. Les deux prendront (à peu près) le même temps pour résoudre l'instance problématique. Théoriquement, partout où vous en utilisez un, vous pouvez également utiliser l'autre. Vous avez juste besoin de convertir des nombres de unaire en binaire et vice versa.$W=\{w_1, \ldots, w_n\}$$k$$O(nk)$

Quel est donc l'intérêt de définir la complexité des algorithmes par rapport à la taille des entrées? Pourquoi ne pas toujours les énoncer en termes de paramètres comme ?$O(nk)$

Si vous vous souciez d'un problème isolément, vous pouvez le faire. En fait, c'est ce que font souvent les utilisateurs d'algorithmes. La complexité des algorithmes de graphe est souvent exprimée en termes de nombre de sommets et de nombre d'arêtes, et non de la taille de la chaîne qui les code.

Mais ce n'est que lorsque nous avons affaire à un problème isolé. Il n'est pas utile lorsque nous traitons des problèmes avec différents types d'entrées. Pour les graphiques, nous pouvons parler du temps d'exécution par rapport au nombre de sommets et d'arêtes. Pour Knapsack, nous pouvons parler du nombre d'articles et de la taille du Knapsack. Mais que faire si nous voulons parler des deux? Par exemple, lorsque nous voulons réduire les problèmes ou discuter d'une classe de problèmes qui inclut des problèmes arbitraires, pas seulement ceux avec un graphique en entrée. Nous avons besoin d'un paramètre universel d'entrées. Une entrée en général n'est qu'une chaîne, c'est nous qui interprétons ses symboles comme des nombres unaires, des nombres binaires, des graphiques, etc. Pour développer une théorie générale de la complexité de l'algorithme et des problèmes, nous avons besoin d'un paramètre général des entrées. La taille de l'entrée est un choix évident et elle s'avère suffisamment robuste pour que nous puissions construire une théorie raisonnable par-dessus. Ce n'est pas la seule possibilité. Pour un artificiel, nous pouvons construire une théorie basée sur à la taille de l'entrée. Cela fonctionnera bien.$2$

Maintenant, nous décidons d'utiliser la taille comme paramètre universel des entrées, cela nous oblige à penser au codage des objets en termes de chaînes. Il existe différentes manières de les coder et elles peuvent avoir différentes tailles. (Ils rendent également différentes choses faciles / difficiles.) En termes de théorie générale des algorithmes, que nous codions le nombre d'entrée en unaire ou binaire devient important. Si nous utilisons unaire et que la taille de est 100, le plus grand nombre que nous obtiendrons est 100 . Si nous utilisons le binaire, k peut être aussi grand que 2 100 - 1 . Donc, quand nous parlons du temps d'exécution de la résolution des problèmes de sac à dos où la taille de $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$

En bref et simple, je vais vous montrer pourquoi.

$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 représentation d'entrée ne rend pas le code plus rapide. Même si le 2ème algorithme est vraiment poly-temps. Ce n'est pas très pratique pour trouver les facteurs de RSA.