La complexité des problèmes fortement NP-durs ou complets change-t-elle lorsque leur entrée est codée unaire?

12

La difficulté d'un problème fortement NP-dur ou NP-complet (tel que défini ici par exemple ) change-t-elle lorsque son entrée est unaire au lieu d'être codée en binaire?

Quelle différence cela fait-il si l'entrée d'un problème fortement NP-dur est codée unaire? Je veux dire, si je prends par exemple le problème du sac à dos faiblement NP-complet, il est NP-complet lorsqu'il est codé en binaire mais peut être résolu en temps polynomial par programmation dynamique lorsqu'il est codé unaire. Peut-être cela a-t-il des implications sur la dureté des niveaux supérieurs de la hiérarchie polynomiale temporelle?

La notion de fortement ...- dur s'applique-t-elle également à d'autres classes de complexité, par exemple les classes supérieures de la hiérarchie polynomiale temporelle?

J'ai déjà posé cette question sur stackoverflow.com mais il a été souligné qu'elle est plus appropriée ici.

complexity-theory time-complexity np-complete

— user2145167
source

Dois-je peut-être mieux poser cette question sur cstheory.stackexchange.com ? Je ne savais tout simplement pas que cela existait. Les demandes ici ne vont pas dans la direction que j'espérais.

— user2145167

Pourquoi pas? Ils sont (pour autant que je sache) corrects, alors peut-être que votre question n'est pas celle que vous voulez poser? En outre, l' informatique théorique est destinée aux questions TCS de niveau recherche , ce qui n'est certainement pas le cas.

— Raphael

4

Un problème de taille codé en unaire est la taille et si binaire. Si le temps pris est , c'est dans le premier cas et dans le second cas. Un algorithme polynomial pour le premier cas sera donc exponentiel pour le second. L'encodage du problème peut donc changer radicalement la complexité d'un algorithme. $N$ $N$ $\log N$ $F(N)$ $F(\text{size})$ $F(2^{\text{size}})$

— vonbrand
source

3

Non.

Si vous modifiez l'encodage de l'entrée, vous avez modifié la définition formelle du problème, ce qui signifie qu'il s'agit d'un problème différent . La complexité du problème d'origine ne change pas, pour la même raison que le fait de pointer une lumière différente dans le ciel ne change pas la masse de la lune.

— JeffE
source

2

Je pense que la question est de savoir si pour tout problème NP-dur la version unaire n'est pas NP-dure.

P

$P$

P_{1}

$P_1$

— Raphael

2

La réponse courte est que si l'entrée est codée unaire, elle est plus longue . Il est exponentiellement plus long. Maintenant, un algorithme qui fonctionne en temps polynomial dans la taille de l'entrée a "suffisamment de temps" pour résoudre le problème, simplement parce que l'entrée elle-même est exponentiellement plus longue que dans le problème d'origine.

— A sonné.
source

1

Vu le problème de formulation passé dans la réponse de JeffE, la réponse est oui.

Considérez le problème du sac à dos . Il possède un algorithme pseudo-polynomial , c'est-à-dire dont l'exécution est limitée par un polynôme en nombre codé dans l'entrée. Étant donné que dans le codage unaire, les valeurs correspondent à la longueur, il s'agit d'un algorithme à temps polynomial pour la version unaire.

En fait, chaque problème faiblement NP-complet tombe dans cette catégorie.

— Raphael
source

Question secondaire, mais je n'ai jamais compris - comment "encodez-vous" quelque chose en unaire? N'avez-vous pas besoin d'un délimiteur quelconque?

— user541686

@Mehrdad Oui et non. Oui; les symboles de séparation ne sont généralement pas comptés dans ce sens, cf. également entrée vs alphabet bande; ici, nous considérons uniquement la taille de l'alphabet saisi. Non; en principe, un seul nombre suffit pour encoder des tuples et des ensembles de nombres dénombrables afin que vous n'ayez pas besoin de symboles de séparation. Ce n'est clairement pas utile pour "travailler" avec de telles machines, mais cela justifie d'ignorer les symboles de séparation (et autres commandes).

— Raphael

Hmm ... Je ne suis pas sûr de comprendre votre "non"; comment sauriez-vous où se termine le numéro si vous n'aviez pas de séparateur à la fin? Cela me semble un peu comme une logique circulaire: si nous ignorons les séparateurs, alors la question devient "si nous forçons l'entrée à occuper de manière exponentielle plus d'espace, cela change-t-il le temps d'exécution d'un algorithme exponentiel par rapport à la taille de l'entrée ? " dont la réponse est trivialement oui ... par définition. Il ne s'agit pas tant de changer l'encodage que d'ajouter artificiellement des bits redondants une fois que vous tenez compte des séparateurs.

— user541686

@Mehrdad D'accord, je ne pensais qu'à séparer plusieurs numéros les uns des autres. Dans tous les cas, vous avez besoin de repères de fin resp. symboles "vides" sur les machines Turing; dont vous ne pouvez pas vous débarrasser. Le reste, vous pouvez l'encoder en un seul numéro (avec une pénalité d'exécution, évidemment).

— Raphael