Почему бы не взять одинарное представление чисел в числовых алгоритмах?

Алгоритм псевдополиномиального времени - это алгоритм, который имеет полиномиальное время работы на входном значении (величина), но экспоненциальное время работы на входном размере (количество бит).

Например, для проверки, является ли число простым или нет, требуется выполнить цикл по числам от 2 до n - 1 и проверить, является ли n mod i нулевым или нет. Если мод занимает O (1) времени, общая сложность времени будет O (n).$n$$n-1$$n$ $i$

Но если мы позволим быть числом необходимых битов для записи входных данных, то x = log n (двоичный), поэтому n = 2 x, и время выполнения задачи будет O ( 2 x ), что является экспоненциальным.$x$$x = \log n$$n = 2^x$$2^x$

Мой вопрос заключается в том, что если мы рассмотрим унарное представление входного , то всегда x = n и тогда псевдополиномиальное время будет равно сложности полиномиального времени. Так почему же мы никогда этого не делаем?$n$$x=n$

Более того, поскольку для рюкзака существует алгоритм псевдополиномиального времени, при взятии рюкзак будет полиномиальным в результате P = NP$x=n$

Это означает, что унарный рюкзак находится в P. Это не означает, что рюкзак (с двоичными числами) находится в P.

Рюкзак, как известно, NP-полный. Если бы вы показали, что рюкзак находится в P, это показало бы, что P = NP.

Но вы не показали, что рюкзак находится в P. Вы показали, что унарный рюкзак находится в P. Однако, как известно, унарный рюкзак не является NP-полным (действительно, стандартное подозрение заключается в том, что он, скорее всего, не является NP-полным). ). Следовательно, помещение одинарного ранца в P не означает, что P = NP.

Так о какой проблеме нас больше заботит, рюкзак или унарный рюкзак? Если ваша мотивация основана на практических соображениях, то ответ будет зависеть от размера чисел, для которых вы хотите решить проблему с рюкзаком: если они большие, то вы, конечно, больше заботитесь о рюкзаке, чем об одноместном рюкзаке. Если ваша мотивация основана на теоретических соображениях, то рюкзак, возможно, более интересен, потому что он позволяет нам глубже понять - он позволяет нам проводить различие между размером и величиной - тогда как унарный рюкзак мешает нам сделать это различие.

Чтобы ответить на следующий вопрос об алгоритме динамического программирования для задачи о ранце:

Да, один и тот же алгоритм динамического программирования может применяться как к рюкзакам, так и к одинарным рюкзакам. Время его выполнения является полиномиальным по величине чисел, но экспоненциальным (не полиномиальным) по длине чисел при кодировании в двоичном виде. Таким образом, его время работы является полиномиальным по длине входа, когда вход кодируется в унарном виде, но не является полиномиальным по длине входа, когда вход кодируется в двоичном формате. Вот почему мы действительно рассмотреть этот алгоритм динамического программирования быть полиномиальным алгоритмом для одноместный рюкзаке, но не считаем , что это полиномиальный алгоритм (бинарной кодировкой) ранец.

Напомним, что мы говорим, что алгоритм выполняется за полиномиальное время, если его время выполнения не больше некоторого полинома длины входа в битах .

Я бы добавил одну маленькую вещь к ответу DW:

Я видел людей, которые думают, что поскольку унарный рюкзак находится в P, мы можем использовать его вместо рюкзака, у которого лучшие современные алгоритмы имеют экспоненциальное время.

Пусть входом будет и k и рассмотрим алгоритм динамического программирования для рюкзака и унарного рюкзака. Время работы для них обоих O ( n k ) . Это то же самое время выполнения. Т.е., если у вас есть вход, не имеет значения, используете ли вы динамическое программирование для унарного рюкзака или динамическое программирование для рюкзака. Им обоим потребуется (примерно) одинаковое количество времени для решения проблемы. Теоретически, где бы вы ни использовали одно, вы можете использовать и другое. Вам просто нужно преобразовать числа из одинарных в двоичные и наоборот.$W=\{w_1, \ldots, w_n\}$$k$$O(nk)$

Так какой смысл определять сложность алгоритмов в зависимости от размера входных данных? Почему бы не всегда указывать их в терминах параметров как ?$O(nk)$

Если вы заботитесь о проблеме в изоляции, вы можете сделать это. На самом деле это то, что люди в алгоритмах часто делают. Сложность алгоритмов графа часто выражается через число вершин и количество ребер, а не размер строки, которая их кодирует.

Но это только тогда, когда мы имеем дело с изолированной проблемой. Это бесполезно, когда мы имеем дело с проблемами с различными видами входных данных. Для графов мы можем говорить о времени выполнения по числу вершин и ребер. Для рюкзака можно говорить о количестве предметов и размере рюкзака. Но что, если мы хотим поговорить об обоих? Например, когда мы хотим сократить число проблем или обсудить класс проблем, который включает в себя произвольные задачи, а не только те, у которых в качестве входных данных используется граф. Нам нужен универсальный параметр входов. В общем случае входные данные - это просто строка, именно мы интерпретируем их символы как унарные числа, двоичные числа, графики и т. Д. Для разработки общей теории сложности алгоритма и задач нам необходим общий параметр входных данных. Размер входных данных является очевидным выбором, и он оказывается достаточно надежным, чтобы на нем можно было построить разумную теорию. Это не единственная возможность. Для искусственного мы можем построить теорию, основанную на$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$

Короче говоря, я покажу вам, почему.

Предположим, у вас есть алгоритм факторизации. За исключением небольшой разницы, что один принимает целые числа для ввода, а другой$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)

Входное представление не заставляет код работать быстрее. Несмотря на то, что 2-й алгоритм действительно много времени. Это не очень практично в поиске факторов для RSA.