Warum nicht die unäre Darstellung von Zahlen in numerischen Algorithmen nehmen?

Ein Pseudo-Polynom-Zeit-Algorithmus ist ein Algorithmus, der eine Polynomlaufzeit für den Eingabewert (Größe), aber eine Exponentiallaufzeit für die Eingabegröße (Anzahl der Bits) aufweist.

Zum Beispiel erfordert das Testen, ob eine Zahl eine Primzahl ist oder nicht, eine Schleife durch die Zahlen von 2 bis und prüft, ob mod Null ist oder nicht. Wenn der Mod O (1) -Zeit benötigt, ist die Gesamtzeitkomplexität O (n).$n$$n-1$$n$ $i$

Aber wenn wir die Anzahl der erforderlichen Bits zum Schreiben der Eingabe sein lassen, dann ist x = log n (binär), also und die Laufzeit des Problems ist O ( ), was exponentiell ist.$x$$x = \log n$$n = 2^x$$2^x$

Meine Frage ist, wenn wir die unäre Darstellung von Eingabe , dann ist immer und dann ist die Pseudo-Polynomzeit gleich der Komplexität der Polynomzeit. Warum machen wir das nie?$n$$x=n$

Da es ferner einen Pseudo-Polynom-Zeitalgorithmus für den Rucksack gibt, wird der Rucksack, indem wird, als Ergebnis P = NP polynomisch sein$x=n$

Dies bedeutet, dass sich der unäre Rucksack in P befindet. Dies bedeutet nicht, dass sich der Rucksack (mit binär codierten Zahlen) in P befindet.

Rucksack ist bekanntermaßen NP-vollständig. Wenn Sie zeigen würden, dass der Rucksack in P ist, würde dies zeigen, dass P = NP ist.

Sie haben jedoch nicht gezeigt, dass der Rucksack in P enthalten ist. Sie haben gezeigt, dass der unäre Rucksack in P enthalten ist. Es ist jedoch nicht bekannt, dass der unäre Rucksack NP-vollständig ist ). Daher impliziert das Einfügen eines unären Rucksacks in P nicht, dass P = NP ist.

Welches Problem sollte uns mehr interessieren, Rucksack oder unärer Rucksack? Wenn Ihre Motivation auf praktischen Bedenken beruht, hängt die Antwort von der Größe der Zahlen ab, für die Sie das Rucksackproblem lösen möchten: Wenn sie groß sind, interessiert Sie sicherlich mehr der Rucksack als der unäre Rucksack. Wenn Ihre Motivation auf theoretischen Überlegungen beruht, ist der Rucksack wahrscheinlich interessanter, weil er uns ein tieferes Verständnis verschafft - es ermöglicht uns, zwischen Größe und Größe zu unterscheiden -, wohingegen der unäre Rucksack uns daran hindert, diese Unterscheidung zu treffen.

So beantworten Sie die folgende Frage zum dynamischen Programmieralgorithmus für das Rucksackproblem:

Ja, derselbe dynamische Programmieralgorithmus kann sowohl auf den Rucksack als auch auf den unären Rucksack angewendet werden. Ihre Laufzeit ist in der Größe der Zahlen polynomisch, in der Länge der Zahlen jedoch exponentiell (nicht polynomisch), wenn sie binär codiert ist. Somit seine Laufzeit ist Polynom in der Länge des Eingangs , wenn die Eingabe in unäre codiert wird , ist aber nicht in der Länge der Eingangs - Polynom , wenn der Eingang in binär codiert ist. Deshalb haben wir nicht diesen dynamischen Programmieralgorithmus betrachten ein Polynom-Algorithmus für einstelligen Ranzen sein, aber nicht betrachten es als ein Polynom-Algorithmus für (binär codiert) Tornister sein.

Denken Sie daran, dass wir sagen, ein Algorithmus läuft in Polynomzeit, wenn seine Laufzeit höchstens ein Polynom der Länge der Eingabe in Bits ist .

Ich würde der Antwort von DW noch eine Kleinigkeit hinzufügen:

Ich habe Leute gesehen, die denken, dass, weil der unäre Knapsack in P ist, wir ihn anstelle des Knapsacks verwenden können, dessen beste aktuelle Algorithmen exponentielle Zeit haben.

Sei die Eingabe und k und betrachte den dynamischen Programmieralgorithmus für Knapsack und unären Knapsack. Die Laufzeit für beide von ihnen sind O ( n k ) . Es ist die gleiche Laufzeit. Dh wenn Sie eine Eingabe haben, spielt es keine Rolle, ob Sie die dynamische Programmierung für unary Knapsack oder die dynamische Programmierung für Knapsack verwenden. Beide benötigen (ungefähr) dieselbe Zeit, um die Probleminstanz zu lösen. Theoretisch kann man überall, wo man eins benutzt, auch das andere benutzen. Sie müssen nur Zahlen von unär nach binär konvertieren und umgekehrt.$W=\{w_1, \ldots, w_n\}$$k$$O(nk)$

Worum geht es also bei der Definition der Komplexität von Algorithmen in Abhängigkeit von der Größe der Eingaben? Warum geben Sie sie nicht immer als ?$O(nk)$

Wenn Ihnen ein Problem im Alleingang wichtig ist, können Sie dies tun. Tatsächlich ist es das, was Menschen in Algorithmen oft tun. Die Komplexität von Grafikalgorithmen wird häufig durch die Anzahl der Eckpunkte und die Anzahl der Kanten ausgedrückt, nicht durch die Größe der Zeichenfolge, die sie codiert.

Dies ist jedoch nur dann der Fall, wenn es sich um ein isoliertes Problem handelt. Dies ist nicht sinnvoll, wenn wir Probleme mit verschiedenen Arten von Eingaben haben. Bei Diagrammen können wir über die Laufzeit in Bezug auf die Anzahl der Eckpunkte und Kanten sprechen. Bei Knapsack können wir über die Anzahl der Artikel und die Größe des Knapsacks sprechen. Aber was ist, wenn wir über beides sprechen wollen? Zum Beispiel, wenn wir die Anzahl der Probleme reduzieren oder eine Klasse von Problemen diskutieren möchten, die beliebige Probleme enthält, nicht nur solche mit einem Graphen als Eingabe. Wir brauchen einen universellen Parameter von Eingaben. Eine Eingabe ist im Allgemeinen nur eine Zeichenfolge. Wir interpretieren ihre Symbole als unäre Zahlen, Binärzahlen, Diagramme usw. Um eine allgemeine Theorie der Komplexität von Algorithmen und Problemen zu entwickeln, benötigen wir einen allgemeinen Parameter für Eingaben. Die Größe der Eingabe ist eine naheliegende Wahl und es stellt sich heraus, dass sie robust genug ist, um darauf eine vernünftige Theorie aufzubauen. Es ist nicht die einzige Möglichkeit. Für einen Künstlichen können wir eine Theorie aufbauen, die darauf basiert auf die Größe der Eingabe. Es wird gut funktionieren.$2$

Jetzt entscheiden wir uns, die Größe als universellen Parameter für Eingaben zu verwenden. Sie zwingt uns, über die Codierung von Objekten in Form von Zeichenfolgen nachzudenken. Es gibt verschiedene Möglichkeiten, sie zu codieren, und sie können unterschiedliche Größen haben. (Sie machen auch verschiedene Dinge leicht / schwer.) Im Sinne einer allgemeinen Theorie von Algorithmen wird es wichtig, ob wir die eingegebene Zahl in unär oder binär codieren. Wenn wir unary verwenden und die Größe von 100 ist, erhalten wir die größte Zahl von 100 . Wenn wir binäres k verwenden, kann es bis zu 2 100 - 1 groß sein . Wenn wir also über die Laufzeit der Lösung von Knapsack-Problemen sprechen, bei denen die Größe von $k$$100$$100$$k$$2^{100}-1$$k$ist 100 ergeben sich zwei sehr unterschiedliche Situationen: In einem Fall kümmern wir uns nur um Eingaben, bei denen höchstens 100 ist. In dem anderen Fall kümmern wir uns um Eingaben, die bis zu 2 100 - 1 groß sein können .$k$$2^{100}-1$

Angenommen, ich möchte sehen, ob ich SAT in Polynomialzeit auf Knapsack reduzieren kann. Angenommen, die Eingabeformel für SAT hat die Größe . Dann kann ich nur eine Eingabe für Knapsack erstellen, die ein Größenpolynom in n hat . Angenommen, p ( n ) ist die Größe der Eingabe für Knapsack, die ich erstelle. Wenn ich unary benutze, kann ich k nur so setzen , dass es höchstens p ( n ) ist . Wenn ich binär verwende, kann ich k auf 2 p ( n ) - 1 setzen . Es stellt sich heraus, dass ich k setzen muss$n$$n$$p(n)$$k$$p(n)$$k$$2^{p(n)}-1$$k$ziemlich groß, um SAT auf Knapsack reduzieren zu können. Daher funktioniert unary Knapsack nicht, um SAT darauf zu reduzieren. Binary Knapsack würde jedoch funktionieren. Wir werden in der Lage sein, eine Knapsack-Instanz mit viel größerem zu erstellen, wenn wir Binärdateien verwenden.$k$

Eine andere Möglichkeit, darüber nachzudenken: Angenommen, Sie haben eine Black Box, die den unären Knapsack löst, und eine andere, die den Knapsack löst. Angenommen, Sie haben Zeit, einen Bit-Eingang für die Blackbox zu schreiben . Welche der Blackboxen ist leistungsstärker? Offensichtlich derjenige, der binäre Codierung verwendet. Wir können es verwenden , um Knapsack Probleme zu lösen , die exponentiell größer haben k , um Probleme zu vergleichen , dass die einstellige Knapsack Blackbox lösen kann.$n$$k$

Kurz und einfach, ich zeige Ihnen warum.

$Tally$

x = input integer

factors = [];

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

 print(factors)

Notice that the above algorithm is polynomial of the numeric value of $x$. It will take $x$ amount of steps in the loop. But when it comes to bit-size its actually $O(2^n)$.

Suppose, I make a small edit to the code that will take in $Tally/Unary$. Es wird jetzt sein$O(n)$ Zeit in Wert und Länge der Eingabe $x$.

x = input tallies

factors = [];

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

 print(factors)

Durch die Eingabedarstellung wird der Code nicht schneller ausgeführt. Auch wenn der 2. Algorithmus wirklich Polyzeit ist. Es ist nicht sehr praktisch, um die Faktoren für RSA zu finden.