За яких проблем у P легше перевірити результат, ніж знайти його?

52

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

Однак у Р рішення також може бути знайдена в поліноміальний час, тому не здається очевидним, коли перевірка швидша, ніж пошук рішення. Насправді різні проблеми, схоже, поводяться по-різному з цієї точки зору. Деякі приклади:

3SUM: задано вхідних чисел, знайдіть серед них 3, які дорівнюють 0. Наскільки мені відомо, найшвидший відомий алгоритм працює за час , і цей порядок вважається оптимальним. З іншого боку, перевірка рішення відбувається набагато швидше, оскільки все, що нам потрібно зробити, - це лише перевірити, чи знайдені 3 числа дійсно дорівнюють 0. $n$ $O(n^{2-o(1)})$
Найбільш короткі шляхи для всіх пар: задавши графік з вагою ребер, обчисліть його найменшу матрицю відстані в шляху. Після надання такої матриці, чи можна швидше перевірити, чи справді це правильна відстань матриці, ніж її повторне обчислення? Я здогадуюсь, що відповідь, можливо, так, але це, очевидно, менш очевидно, ніж для 3SUM.
Лінійне програмування. Якщо подано заявлене оптимальне рішення, перевірити його простіше, ніж повторно обчислити його, коли також надається допоміжна інформація (оптимальне подвійне рішення). З іншого боку, якщо доступно лише первинне рішення, не ясно, чи можна перевірити його швидше, ніж насправді вирішити LP.

Питання: що відомо про цю тему? Тобто, коли легше перевірити рішення проблеми в P , ніж знайти рішення?

cc.complexity-theory ds.algorithms reference-request

— Андрас Фараго
джерело

7

Я думаю, що багато прикладів виникають із повних NP-проблем, які потрапляють у P, коли ми фіксуємо деякі параметри. Наприклад, перевірка, чи містить графік кліку розміром для фіксованого . Перевірка займає лінійний час, але якщо P = NP, складність проблеми пошуку (полінома) залежить від

k

$k$

k

$k$

k

$k$

— Marzio De Biasi

16

Ми можемо перевірити, що список з цілих чисел відсортований за допомогою порівнянь, але для порівняння несортованого списку потрібно порівняння .

n

$n$

n - 1

$n-1$

Θ (n \log n)

$\Theta(n \log n)$

— Томас

7

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

— Робін Котарі

3

"З іншого боку, перевірка рішення відбувається набагато швидше, оскільки все, що нам потрібно зробити, - це лише перевірити, чи знайдені 3 числа дійсно до 0." - Нам також потрібно перевірити, чи знайдені 3 числа насправді є частиною вхідних даних.

— hvd

3

Чи є проблеми, для яких ми знаємо, що перевірка не є легшою?

— Рафаель

24

відомо, що з урахуванням графіка G і дерева T можна за лінійним часом перевірити, що T є мінімальним прольотним деревом G. Але ми ще не маємо детермінованого алгоритму лінійного часу для обчислення MST. Звичайно, розрив невеликий (1 vs ), але він все ще є :)) $\alpha(n)$

— Суреш Венкат
джерело

4

Можливо, справедливо додати, що існує рандомізований алгоритм, який працює у очікуваний лінійний час (алгоритм Каргера-Клейна-Таряна).

— Сашо Ніколов

2

Крім того, якщо хтось хоче посилання, це найпростіший алгоритм підтвердження лінійного часу MST, про який я знаю: webhome.cs.uvic.ca/~val/Publications/Algorithmica-MSTverif.ps .

— Сашо Ніколов

20

У цьому документі показано, що існують алгоритми перевірки як для YES, так і NO для 3-х задач, включаючи Max Flow, 3SUM і APSP, які швидше поліноміальним коефіцієнтом, ніж відомі межі для обчислення самого рішення.

Існує клас проблем, а саме ті, які покращують час роботи є SETH-важким, час роботи якого для перевірки екземплярів NO навряд чи буде значно швидшим, ніж час для обчислення рішення, інакше гіпотеза з цієї статті називається недетермінованою Сильна експоненціальна часова гіпотеза не зможе.

— Thatchaphol
джерело

18

Для деяких проблем, схоже, немає різниці. Зокрема, шоу Васильська Вільямс та Вільямс :

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

(Тепер, звичайно, можливо, що всі ці проблеми мають субкубічні алгоритми, і тоді може виникнути поліноміальна різниця між обчисленнями та верифікацією, але для цих проблем не може бути кубічної різниці. І мені здається правдоподібним, що в адже всі вони потребують по суті кубічного часу.)

— Джошуа Грохов
джерело

2

З іншого боку, для множення матриць у досить великому полі існує квадратичний рандомізований алгоритм для верифікації, в той час як найшвидший час для обчислення продукту - n ^ омега.

— Тетчахол

2

@Thatchaphol: Так, хоча багато людей вважають, що омега = 2 ... Крім того, загальновизнано, що булеве множення матриці (тобто обчислення матричного мульти по булевому та / або півкільцю) має дещо інший характер, ніж множення матриці на a поле.

— Джошуа Грохов

16

Вирішення того, чи існує значення в масиві, вимагає часу (або якщо масив відсортований). $\Omega(n)$ $\Omega(\log n)$

Перевірити, що масив містить задане значення в заданій позиції, можливо за час . $O(1)$
Сортування (у моделі порівняння) вимагає часу , але перевірити, чи можна сортувати масив чи список, можливий за час . $\Omega(n \log n)$ $O(n)$

— Рафаель
джерело

2

Аналогічно: визначення, чи є дублікат елемента в моделі порівняння, але, звичайно, може бути перевірено в .

Ω (n \log n)

$\Omega(n \log n)$

O (1)

$O(1)$

— СамМ

@SamM: Ви маєте на увазі підтверджені в ? Що вам дано саме? Я відчуваю, що ти робиш несправедливе порівняння.

O (n)

$O(n)$

— Мехрдад

@Mehrdad хороший момент; якщо вам надано значення (а не індекси), це перевірити. Я бачу хороший аргумент, що це кращий спосіб поглянути на це.

Θ (n)

$\Theta(n)$

— СамМ

10

Я думаю, що багато прикладів виникають із повних NP-проблем, які потрапляють у P, коли ми фіксуємо один або кілька параметрів .

Наприклад, перевірка, чи графік містить кліку розміром є NP-повною, якщо є частиною вхідного сигналу, який вирішується багаточленним часом, якщо є фіксованим. $k$ $k$ $k$

Для будь-якого фіксованого перевірка займає лінійний час, але якщо , складність задачі пошуку (полінома) залежить від ( . $k$ $P=NP$ $k$ $\Omega(n^k) )$

Інші приклади: пошук гамільтонового шляху довжиною , забарвлення на обмежених графіках ширини, ... $k$

— Марціо Де Біасі
джерело

9

Вирішення первинності: найвідоміший варіант АКС, мабуть, визначає первинність у часі , тоді як класичний сертифікат первинності Пратта передбачає, що первинність може бути вирішена в недетермінований час . $\tilde{O}(n^6)$ $\tilde{O}(n^3)$

— Джо Бебель
джерело

доповнення (композитність) ще простіше засвідчити!

— Yonatan N

3

Стаття Аббуда і ін. Нещодавно прийнята до SODA 2016 показує, що підмережевий ізоморфізм не може бути вирішений за час якщо сильна гіпотеза експоненціального часу не помилкова. Звичайно, ми можемо перевірити ізоморфізм у лінійному часі. $O(n^{2-\epsilon})$

Іншими словами, SETH задає нам природну проблему в з розривом між знаходженням і підтвердженням. $\sf{P}$ $\Omega(n^{1-\epsilon})$

Зокрема, алгоритм відомий для вкорінених дерев з постійним ступенем (для яких результати нижньої межі Abboud et al. Все ще застосовуються). Отже, за SETH, майже лінійний розрив знаходження-перевірки є суттєвим для цієї проблеми. $O(n^2/\log n)$

— СамМ
джерело