Чому проблема рюкзака псевдополіном?


87

Я знаю, що Knapsackце NP-повно, хоча це може бути вирішено DP. Вони кажуть, що рішення DP є pseudo-polynomial, оскільки воно є експоненціальним за "довжиною вводу" (тобто кількістю бітів, необхідних для кодування вводу). На жаль, я не зрозумів. Хто-небудь може pseudo-polynomialповільно пояснити мені це?


Відповіді:


89

Час роботи становить O (NW) для необмеженої проблеми рюкзака з N предметами та рюкзака розміром W. W, однак, не є поліномом за довжиною введення, саме це робить його псевдополіноміальним .

Розглянемо W = 1 000 000 000 000. Для представлення цього числа потрібно лише 40 біт, тому розмір вводу = 40, але обчислювальний час використання використовує коефіцієнт 1 000 000 000 000, що дорівнює O (2 40 ).

Тож час виконання є більш точним, як O (N.2 біт у W ), який є експоненціальним.

Також див.


1
Посилання №3, яке посилається на "Складність динамічного програмування для проблеми рюкзака 0-1", мертве.
dev_nut

1
Вибачте, я не зрозумів. Скажімо, якщо у нас є алгоритм із часовою складністю O (N), то маємо O (2 ^ (біти в N)), який є експоненціальним? Дякую ~
Lusha Li

3
@LushaLi Це мені допомогло: youtube.com/watch?v=9oI7fg-MIpE . Якщо N - масив, де кожен елемент має фіксований максимальний розмір вводу (скажімо, кожен елемент масиву не перевищує 32 біт), і ви один раз запускаєте цикл for на цьому масиві, то це вхідний алгоритм полінома на вході розмір N масиву. Однак, якщо N є цілим числом, і ви запускаєте цикл над N, то N необмежений і зростає експоненціально в кількості бітів, необхідних для його представлення. Отже, простий цикл for на N насправді є експоненціальним. Зверніть увагу, що у випадку масиву розмір кожного елемента в масиві був обмежений верхніми межами.
max_max_mir

Я не був переконаний. Є багато алгоритмів з однаковими властивостями, які не є “псевдополіномами”. Скажіть, у чому складність решета Ератосфена (або будь-якого іншого шукача простих чисел)?
Офір А.

31

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

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

Але спробуйте переробити інші алгоритми, щоб діяти на наборах даних, що включають великі ints - числа, що вимагають більше 8 байт для представлення, - і подивіться, що це впливає на час виконання. Величина залучених чисел завжди має різницю, навіть в інших алгоритмах, таких як двійкове сортування, коли ви розширюєтеся за межі буфера безпеки, звичайні процесори дають нам "безкоштовно", обробляючи партії 4-8 байт.

Фокус з алгоритмом Knapsack, який ми обговорювали, полягає в тому, що він надзвичайно чутливий (щодо інших алгоритмів) до величини певного параметра W. Додайте один біт до W, і ви подвоюєте час роботи алгоритму. Ми не бачили такої різкої реакції на зміну вартості в інших алгоритмах до цього, ось чому може здатися, що ми поводимось із Knapsack по-іншому - але це справжній аналіз того, як він реагує неполіноміальним способом до змін у розмірі вводу.


8

Час роботи алгоритму Knapsack пов'язаний не тільки з розміром вводу (n - кількість елементів), але також і з величиною входу (W - місткість рюкзака) O (nW), яка експоненціальна щодо того, як це представлені в комп'ютері в двійковому (2 ^ n). Складність обчислень (тобто спосіб обробки всередині комп'ютера через біти) стосується лише розміру входів, а не їх величин / значень .

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

Ще одним простим прикладом, який допоміг мені зрозуміти псевдополіноміальну концепцію, є наївний алгоритм тестування первинності. Для даного числа n ми перевіряємо, чи поділено воно рівномірно на кожне ціле число в діапазоні 2..√n, тому алгоритм виконує √ (n − 1) кроків. Але тут n - величина вхідного сигналу, а не його розмір.

                     Now The regular O(n) case

Навпаки, пошук масиву для даного елемента виконується в поліноміальному часі: O (n). Це займає щонайбільше n кроків, і тут n - розмір вводу (довжина масиву).

[див. тут]

Обчислення бітів, необхідних для збереження десяткового числа


3
Тож для вашого останнього прикладу пошуку, чому б ви також не розглядали n як двійковий? якщо n = 1024, це також займає лише 10 біт, то чи не повинен це бути псевдополіном?
user1024

7

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

Подумайте про введення як про "масив речей", а про розмір як про "скільки речей у масиві". Введення елемента насправді є масивом з n елементів у масиві, тому size = n. Введена ємність - це НЕ масив чисел W , а одне ціле число , представлене масивом журналів (W) бітів. Збільште його розмір на 1 (додавши 1 значущий біт), W подвоюється, тому час виконання подвоюється, отже, експоненціальна складність часу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.