Наскільки поширені алгоритми експоненціального часового загального випадку у виробничому програмному забезпеченні?

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

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

Ті проблеми з верфіфікацією, які насправді піддаються обчисленню (бар'єр №1), часто є EXPTIME - жорсткі, у більш щасливих випадках ви отримуєте неповні проблеми PSPACE (бар'єр №2). Обидва класи (підозрювані) є складнішими, ніж проблеми, що завершуються NP, які порівняно прості. Двозначні експоненціальні проблеми також легко отримуються.

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

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

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

Дозвольте взяти приклад проблеми продавця подорожей. Я працював над цим кілька разів.

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

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

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

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