Що таке приклад обчислювально неможливої ​​бізнес-проблеми?

У мене є колега, який відмовляється прийняти реальність, що машини Тьюрінга (і машини Von Neuman за розширенням) не можуть вирішити власну проблему зупинки:

Зробити все, що завгодно, і гроші ви можете зробити що завгодно.

Він також не любить теоретичні проблеми, стверджуючи, що:

У нашому полі ми ніколи не будемо стикатися з цими питаннями. Ми розробники додатків, а не вчені-теоретики.

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

Технічно неможливо, але ...

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

Інші приклади проблем, які технічно неможливі, але є технічно складними, можна знайти тут .

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

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

Так само проблема зупинки важлива для теоретиків, але вона не має особливого значення для більшості підприємств.

Інші прокоментували це, але я спробую виписати відповідь, даючи свою точку зору.

Мені подобається відповідь Роберта Харві та коментарі до його відповіді, і я хотів би розширити їх.

Я думаю, що ви повинні представити ці невирішені проблеми (наприклад, припинення) повсякденному способі: наприклад, інструмент IDE, який "перевіряє, чи завжди ця функція повертає значення".

Під час викладання моїм улюбленим прикладом було рефакторинг ( еквівалентність функції, ще одна нерозв'язна проблема ). Я запитав:

як ви перевіряєте, чи функція / програма робить те ж саме після вашого приємного рефакторингу? Звичайно, для нас є одиничні тести, але вони охоплюють не всі випадки. І вони нудно писати ... Але ми програмісти! Ми повинні написати програму, яка перевіряє, чи дають ці дві функції завжди однаковий результат! Чому б не спробувати написати це?

або, як варіант, можливо, ближче до вашого випадку:

Цей застарілий код написаний на древньому незрозумілому діалекті COBOL, для якого немає специфікацій та / або компіляторів. У нас є лише програма. Весь наш бізнес покладається на це, тому ми повинні бути на 100% впевнені, що новий код Java робить точно так само у будь-якій ситуації. Керівництво хоче, щоб програма, яка це зробила, перевірила всі можливі випадки і підрахувала, що це може бути зроблено через 6 - 8 тижнів. Чому б не спробувати написати це?

Справа не в тому, щоб писати таку програму. Або досить гарне наближення вимог. Сенс у тому, щоб усвідомити, що НЕ МОЖЕ зробити це прямо, НЕ марнуйте незліченну кількість наших, намагаючись придумати, як це зробити (лише зрозуміти, що це неможливо), але визнайте це. "Ах, це не можна визначити! Це неможливо зробити безпосередньо. Мені потрібно придумати інший, більш розумний спосіб зробити це з досить хорошим наближенням".

Ви повинні знайти спосіб подати проблему впізнаваному, і, мабуть, простому способі. Ви б не повірили, скільки студентів CS спробують написати таку програму відразу ... перед тим, як взяти клас обчислюваності :)

Якщо припустити, що ми можемо покинути моральні питання на даний момент:

Бізнес A підписав з вами спосіб спілкування між супутниковими офісами A1 та A2, без того, щоб хтось, крім уповноважених людей A1 та A2, не міг зрозуміти спілкування.

Бізнес B домовлявся з вами про спосіб розумного підслуховування всіх комунікацій між A1 та A2.

Очевидно, ви не можете зробити і те, і інше.

Через те, як працює математика (точна математика підлягає постійним дослідженням протягом 100 років), одна з таких вимог не може бути задоволена:

(1): Наведіть алгоритм шифрування, який не може бути зламаний зловмисником, довільною кількістю грошей.

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

Нещодавно я взяв заняття з моделі та нотації бізнес-процесів ( BPMN ). Там легко помітити, що робочі процеси з великою кількістю занадто розщеплення, з'єднань і циклів швидко стають непрактичними (хоча це не обов’язково неможливо , AFAIK) для розуміння та контролю (коли ви використовуєте занадто багато АБР-розщеплень замість XOR-розщеплень).

Для галузі програмного забезпечення, я думаю, те саме стосується і подібних проблем "багаторазового охоплення умов" в аналізі покриття коду .

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

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

Класичний приклад - це спроба розбору HTML з регулярними виразами . Це може працювати з обмеженими наборами HTML, але загальне рішення неможливо через те, що вони мають різні граматики Хомського (як зрозуміло посилання (ish)).

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

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

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

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

Ви можете подумати, що подібна програма { while true: print "running"; print "halted"; }є протимірним прикладом, але це не так. Ця програма має побічні ефекти, які можуть або не призведуть до її припинення. Ігноруючи побічні ефекти, можна розробити офіційний доказ того, що ця програма не зупиниться. У цьому питанні ми торкаємося лише програм, які ухиляються від формального підтвердження неприпинення, де питання про зупинку неможливо вирішити. Це не така програма.

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

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

Суть Тьюрінга полягає в тому, що ярликів немає. Єдиний спосіб бути впевненим у тому, чи є проблема обчислювально обґрунтованою, - це написати програму, запустити її та з’ясувати. Маючи достатньо часу та грошей, ви можете написати всі програми, запускати їх назавжди та з часом та знаходити ті, які дають результати (хелтери). Інші ще будуть працювати. У вас у колеги є достатньо часу та коштів для цього?

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

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