Почему задача о рюкзаке псевдополиномиальна?

Я знаю, что Knapsackэто NP-полный, хотя он может быть решен с помощью DP. Они говорят, что решение DP является pseudo-polynomial, поскольку оно экспоненциально по «длине ввода» (то есть количеству битов, необходимых для кодирования ввода). К сожалению, я этого не понял. Кто-нибудь pseudo-polynomialможет медленно объяснить мне эту вещь?

Время выполнения составляет O (NW) для неограниченной задачи о рюкзаке с N предметами и рюкзаком размера W. W не является полиномиальным по длине входных данных, что делает его псевдополиномиальным .

Рассмотрим W = 1 000 000 000 000. Для представления этого числа требуется всего 40 бит, поэтому размер ввода = 40, но вычислительная среда выполнения использует множитель 1 000 000 000 000, который равен O (2 ⁴⁰ ).

Таким образом, время выполнения более точно называется O (N 2 ^{бита в W} ), что является экспоненциальным.

Также см:

• Как понять, что задача о ранце NP-полная?
• NP-полнота рюкзака
• Сложность алгоритма динамического программирования для задачи о ранце 0-1
• Псевдополиномиальное время

В большинстве наших проблем мы имеем дело с большими списками чисел, которые удобно помещаются в стандартные типы данных int / float. Из-за того, что большинство процессоров построено для обработки 4-8-байтовых чисел за раз без дополнительных затрат (по сравнению с числами, которые умещаются, скажем, в 1 байт), мы редко сталкиваемся с изменением времени работы из-за увеличения наших чисел или в пределах диапазонов, с которыми мы сталкиваемся в реальных проблемах, поэтому доминирующим фактором остается просто количество точек данных, n или m факторов, к которым мы привыкли.

(Вы можете представить, что нотация Big-O скрывает постоянный множитель, который делит 32 или 64 бита на данные, оставляя только количество точек данных, когда каждое из наших чисел соответствует этому количеству битов или меньше )

Но попробуйте поработать с другими алгоритмами, чтобы работать с наборами данных, включающими большие целые числа - числа, для представления которых требуется более 8 байтов, - и посмотрите, что это повлияет на среду выполнения. Величина задействованных чисел всегда имеет значение, даже в других алгоритмах, таких как двоичная сортировка, если вы расширяете буфер безопасности, обычные процессоры предоставляют нам «бесплатно», обрабатывая пакеты размером 4-8 байтов.

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

Время выполнения алгоритма ранца зависит не только от размера входных данных (n - количество элементов), но и от величины входных данных (W - вместимость ранца) O (nW), которая экспоненциально зависит от их размера. представлен в компьютере в двоичном формате (2 ^ n). Вычислительная сложность (то есть, как обработка выполняется внутри компьютера с помощью битов) касается только размера входных данных, а не их величин / значений .

На мгновение не обращайте внимания на список значений / веса. Допустим, у нас есть экземпляр с вместимостью рюкзака 2. W принимает два бита во входных данных. Теперь увеличим вместимость ранца до 4, оставив оставшуюся часть входа. Наши входные данные выросли всего на один бит, но вычислительная сложность увеличилась вдвое. Если мы увеличим емкость до 1024, у нас будет всего 10 бит входных данных для W вместо 2, но сложность увеличится в 512 раз. Сложность времени экспоненциально возрастает с размером W в двоичном (или десятичном) представлении. .

Еще один простой пример, который помог мне понять концепцию псевдополинома, - это наивный алгоритм проверки простоты. Для данного числа n мы проверяем, делится ли оно поровну на каждое целое число в диапазоне 2..√n, поэтому алгоритм занимает √ (n − 1) шагов. Но здесь n - это величина входных данных, а не размер.

                     Now The regular O(n) case

Напротив, поиск в массиве данного элемента выполняется за полиномиальное время: O (n). Это занимает не более n шагов, и здесь n - размер входных данных (длина массива).

[ глянь сюда ]

Расчетные биты, необходимые для хранения десятичного числа

Насколько я понимаю, емкость была бы O (W), если бы входная емкость была массивом [1,2, ..., W] , который имеет размер W. Но вход емкости не массив чисел, это одно целое число. Сложность времени об отношениях к размеру входных данных. Размер целого числа не является значение целого числа, а число бит , представляющим его. Позже мы преобразуем это целое число W в массив [1,2, ..., W] в алгоритме, заставляя людей ошибочно думать, что W - это размер, но этот массив не является входом, а само целое число.

Думайте о вводе как о «массиве материалов», а о размере - как о «количестве материалов в массиве». Входной элемент фактически представляет собой массив из n элементов в массиве, поэтому size = n. Входная емкость - это НЕ массив чисел W в нем, а одно целое число , представленное массивом логических (W) битов. Увеличьте его размер на 1 (добавив 1 значащий бит), W удваивается, поэтому время выполнения удваивается, отсюда экспоненциальная временная сложность.