Почему нет алгоритмов аппроксимации для SAT и других задач решения?

У меня NP-полное решение проблемы. Учитывая пример проблемы, я хотел бы разработать алгоритм, который выводит ДА, если проблема выполнима, и НЕТ, в противном случае. (Конечно, если алгоритм не является оптимальным, он будет делать ошибки.)

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

Почему, например, мы не определяем коэффициент аппроксимации как нечто пропорциональное количеству ошибок, которые допускает алгоритм? Как мы на самом деле решаем проблемы решения жадным и неоптимальным образом?

Алгоритмы аппроксимации предназначены только для задач оптимизации, а не для решения задач.

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

Хорошо, можем ли мы определить какое-то другое отношение (давайте назовем это как-то иначе - например, «коэффициент det»), которое количественно определяет количество ошибок, которые допускает алгоритм, для некоторой проблемы решения? Ну, не понятно, как это сделать. Что будет знаменателем для этой фракции? Или, иначе говоря, проблемных экземпляров будет бесконечное число, и для некоторых из них алгоритм даст правильный ответ, а для других он даст неправильный ответ, так что вы получите соотношение, которое «что-то разделенное на бесконечность», и это в конечном итоге становится бессмысленным или не определенным.

В качестве альтернативы, мы можем определить как долю ошибок, допущенных ошибками алгоритма, на проблемных экземплярах размера n . Тогда мы могли бы вычислить предел r n при n → ∞ , если такой предел существует. Это будет$r_n$$n$$r_n$$n \to \infty$быть четко определенным (если предел существует). Однако в большинстве случаев это может быть не очень полезно. В частности, оно неявно предполагает равномерное распределение по проблемным экземплярам. Однако в реальном мире фактическое распределение по проблемным экземплярам может быть неоднородным - часто оно очень далеко от однородного. Следовательно, число, которое вы получаете таким образом, часто не так полезно, как вы могли бы надеяться: оно часто дает ложное представление о том, насколько хорош алгоритм.

Чтобы узнать больше о том, как люди справляются с труднопреодолимостью (NP-твердость), взгляните на « Борьба с труднопреодолимостью: проблемы с NP-полнотой» .

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

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

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

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

В дополнение к существующим ответам, позвольте мне указать, что существуют ситуации, когда имеет смысл иметь приблизительное решение для решения проблемы, но это работает иначе, чем вы думаете.

С этими алгоритмами, только один из двух результатов определен с уверенностью, в то время как другой может быть неправильным. Возьмите тест Миллера-Рабина для простых чисел , например: если тест определяет, что число не простое, этот результат наверняка. Но в другом случае это только означает, что число, вероятно, простое. В зависимости от того, сколько вычислительного времени вы готовы потратить, вы можете повысить свою уверенность в результате, но это не будет 100%, как в случае не первоклассного случая.

Это особенно полезно при решении неразрешимых проблем: вы можете написать инструмент, который пытается решить проблему остановки для определенного фрагмента кода. Если он может найти доказательство того, что программа не будет зацикливаться бесконечно, вы можете заявить об этом со 100% уверенностью. Если вы не можете найти такое доказательство, это может быть просто потому, что поток управления программой слишком сложен для анализа вашего инструмента, но это не является доказательством того, что он будет работать бесконечно. Упрощая управляющие структуры, вы можете создать эквивалентную программу, достаточно простую для того, чтобы инструмент мог доказать, что он наверняка остановится.