Чому не існує алгоритмів наближення для SAT та інших проблем вирішення?

У мене проблема з вирішенням NP. Враховуючи приклад проблеми, я хотів би розробити алгоритм, який видає ДА, якщо проблема здійсненна, і, НІ, інакше. (Звичайно, якщо алгоритм не є оптимальним, він буде робити помилки.)

Я не можу знайти жодних алгоритмів наближення для таких проблем. Я спеціально шукав SAT і виявив на сторінці Вікіпедії про Алгоритм наближення наступне: Ще одне обмеження підходу полягає в тому, що він застосовується лише до проблем оптимізації, а не до "чистих" проблем прийняття рішень, таких як задоволеність, хоча це часто можливо. .

Чому ми, наприклад, не визначаємо коефіцієнт наближення як щось пропорційне кількості помилок, які робить алгоритм? Як ми насправді вирішуємо проблеми вирішення в жадібному та неоптимальному вигляді?

— Рібц
джерело

Існують алгоритми наближення для MAX-SAT.

— Юваль Філімус

MAX-SAT - це не проблема прийняття рішення, ні?

— Рібз

Алгоритми наближення завжди для проблем оптимізації.

— Yuval Filmus

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

— AnoE

Хоча це не є повною відповіддю, це пояснює частину причини: існують важливі проблеми SAT, для яких помилка лише з низьким бітом - не краще, ніж половина бітів неправильна.

— Джошуа

Відповіді:

Алгоритми наближення призначені лише для проблем оптимізації, а не для вирішення проблем.

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

Гаразд, чи можемо ми визначити якесь інше співвідношення (назвемо це чимось іншим - наприклад, "коефіцієнт дет"), яке кількісно визначає кількість помилок, які робить алгоритм, для якоїсь проблеми рішення? Ну, незрозуміло, як це зробити. Який же знаменник для цього дробу? Або, інакше кажучи: буде нескінченна кількість проблемних екземплярів, і для деяких з них алгоритм дасть правильну відповідь, а інші дасть неправильну відповідь, тож ви в кінцевому підсумку маєте співвідношення, яке є "щось поділене на нескінченність", і це закінчується безглуздим або не визначеним.

Крім того, ми могли б визначити, що є часткою помилок, які помилки алгоритму, на проблемних екземплярах розміру . Тоді ми могли б обчислити межу $r_n$ $n$ $r_n$ як , якщо така межа існує. Це було б $n \to \infty$ бути чітко визначеним (якщо ліміт існує). Однак у більшості випадків це може бути не дуже корисно. Зокрема, це неявно передбачає рівномірний розподіл на проблемні екземпляри. Однак у реальному світі фактичний розподіл за проблемними екземплярами може не бути рівномірним - він часто дуже далеко не рівномірний. Отже, отримане таким чином число часто не є таким корисним, як ви могли сподіватися: воно часто створює оманливе враження про те, наскільки хороший алгоритм.

Щоб дізнатися більше про те, як люди поводяться з внутрішньоздатністю (твердістю NP), погляньте на тему "Робота з внутрішньостабільністю: проблеми, повні NP" .

— DW
джерело

+1. Але останній пункт не є твердим, можна стверджувати, що ви можете визначити коефіцієнт наближення як межу, оскільки n переходить до нескінченності кількості помилок, які програма робить при введенні довжини n понад кількість рядків довжини n. Це, звичайно, виявляється не корисним, оскільки часто проста програма, яка просто виводить "ТАК" (або "НІ"), досягає хорошого співвідношення (іноді навіть 1!).

— aelguindy

@det, це окреме питання, яке вам слід задати окремо (прочитавши про це у стандартних підручниках чи інтернет-ресурсах). Ми вважаємо за краще, щоб ви задавали лише одне запитання за повідомлення.

— DW

@aelguindy, хороший момент. Я відповідно оновив свою відповідь.

— DW

@det Чому жадібний? Що означає «майже» вирішити проблему рішення?

— Рафаель

@Mehrdad: Зазвичай ви оцінюєте алгоритм наближення за його найгіршим випадком помилки: верхня межа того, наскільки неоптимальним він є. Так, наприклад, ви можете сказати, що заданий алгоритм наближення завжди знаходить результат, який становить щонайменше п’ять шостих оптимального результату. Немає реального способу перекласти це на вирішення проблеми; якщо ваш алгоритм іноді випромінює (скажімо) 0,1, то або він іноді відключається на 0,9 (у такому випадку ви б краще, у гіршому випадку, завжди випромінювали 0,5), або "приблизна" -ness - це шахрайство і "0,1 "насправді просто означає" 0 ".

— ruakh

Причина, коли ви не бачите таких речей, як коефіцієнти наближення в проблемах прийняття рішень, полягає в тому, що вони, як правило, не мають сенсу в контексті питань, які зазвичай задаються щодо проблем прийняття рішень. В налаштуваннях оптимізації це має сенс, оскільки корисно бути "близьким". У багатьох середовищах це не має сенсу. Немає сенсу бачити, як часто ви «близькі» в дискретному логарифмічному завданні. Немає сенсу бачити, як часто ви «близькі» до пошуку ізомеру графіка. І так само в більшості проблем прийняття рішень не має сенсу бути "близьким" до правильного рішення.

Зараз у практичних реалізаціях є багато випадків, коли корисно знати, яку частину проблем можна вирішити «швидко», а яку - не. Однак, на відміну від оптимізації, немає жодного способу кількісної оцінки цього. Ви можете це робити статистично, як ви пропонуєте, але тільки якщо ви знаєте статистичний розподіл своїх даних. Здебільшого людям, які цікавляться проблемами вирішення, не так пощастило мати такі розподіли.

В якості прикладу розглянемо проблему зупинки. Як відомо, проблема зупинки не може бути вирішена. Прикро, адже це справді корисна проблема, яку можна вирішити, якщо ви робите компілятор. Однак на практиці ми виявляємо, що більшість програм насправді дуже легко проаналізувати з точки зору зупинки. Компілятори скористаються цим для створення оптимального коду в цих умовах. Однак компілятор повинен визнати, що існує можливість того, що певний блок коду не вирішується. Будь-яка програма, яка покладається на те, що код "вірогідний для вирішення", може потрапити в біду.

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

— Корт Аммон - Відновлення Моніки
джерело

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

— Рібз

@det Натисніть назад і відновіть проблему. Якщо у вас є проблема, що завершилася NP, ви досить застрягли, але дуже ймовірно, що її насправді не потрібно вирішувати. Наприклад, вам не завжди потрібна ідеальна відповідь. Можливо, близьке досить добре. Або, можливо, ви зможете вирішити проблему для набору випадків, які є легкими, і киньте на важкі. Наприклад, алгоритми пакування часто не є повними NP, але алгоритми, які надійно потрапляють в межах 5% від оптимальних, використовуючи пробабалістичні підходи.

— Корт Аммон - Відновіть Моніку

Чесно кажучи, сказати про те, щоб придумати жадібний алгоритм для вирішення програми, завершеної NP, є буквально таким же, як завдання, щоб одночасно взяти на себе цілу інформатику / математичну спільноту. Якщо ви знайшли алгоритм для NP-повній програмі в P час, за дуже міру , ви б заробити Clay приз $ 1 млн для вирішення P = NP. Насправді наслідки вашого відкриття дозволить переробити обчислення, як ми це знаємо, і повністю покращити всю безпеку / криптографічну індустрію протягом ночі. Краще, щоб формулювання завдання було скориговано так, щоб воно не було довершеним.

— Корт Аммон - Відновіть Моніку

Я використав жадібний точний алгоритм для вирішення NP-проблеми. Мені потрібно було лише вирішити невеликий випадок, і я міг отримати 64-процесорний сервер на вихідні.

— Патрісія Шанахан

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

За допомогою цих алгоритмів лише один із двох результатів визначається з певністю, а інший може бути невірним. Візьмемо, наприклад, тест Міллера-Рабіна для простих чисел : Якщо тест визначає, що число не є простим, цей результат є певним. Але в іншому випадку це означає лише, що число, ймовірно, є простим. Залежно від того, скільки часу, який ви готові вкласти, ви можете збільшити впевненість у результаті, але це не буде на 100%, як це стосується не простого випадку.

Це особливо потужно при вирішенні невирішених проблем: Ви можете написати інструмент, який намагається вирішити проблему зупинки для конкретного фрагмента коду. Якщо вона зможе знайти доказ того, що програма не буде безперебійно циклічно, ви можете це стверджувати зі 100% впевненістю. Якщо ви не можете знайти таке підтвердження, можливо, потік керування програмою занадто складний, щоб ваш інструмент аналізував, але це не доказ того, що він буде циклічно назавжди. Спростивши структури управління, ви зможете створити еквівалентну програму, достатньо просту для інструменту, щоб довести, що вона зупиниться напевно.

— ComicSansMS
джерело

Існує велика різниця між імовірнісним (ваша відповідь) та апроксимаційним (питанням) алгоритмами. Зокрема, поєднання обох - це дуже особлива порода.

— Рафаель

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

— Рафаель

@Raphael Я не мав намір моя відповідь бути специфічною для імовірнісних алгоритмів. Звичайно, для Міллера-Рабіна це так, але, як ви вже згадували, це більше не стосується прикладу проблеми, що зупиняється, і, мабуть, також не буде правдою для більшості випадків, коли ви виявляєте таку поведінку. Справа, яку я хотів подолати - це просто те, що ви отримаєте впевненість лише в одному результаті, а не в іншому.

— ComicSansMS

Якщо ви не говорите більше, ніж те, що деякі проблеми є лише напівзрахунковими, я не думаю, що ви відповідаєте на це питання.

— Рафаель

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

— ComicSansMS