Свідки математичного програмного забезпечення

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

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

Отже, підсумовуючи, моє запитання таке.

Чи можна, хоча б теоретично, математичне програмне забезпечення дати короткий перевіряється доказ разом із відповідним запитом?

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

1. Поняття "свідків" або "підтверджуваних доказів" не зовсім нове: як зазначено в коментарях, шукайте поняття "довідка". На думку прийшли три приклади, їх більше (у коментарях та інших місцях):

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

   • Демейне, Лопес-Ортіз і Манро в 2000 р. Використовували поняття сертифікатів (вони називають їх «докази»), щоб показати адаптивну нижню межу для обчислення об'єднання та перетину (і різниці, але це тривіально) відсортованих множин. Не виключайте їх роботи, оскільки вони не використовували сертифікати для захисту від помилок при обчисленні: вони показали, що, хоча сертифікат може бути лінійним за розміром екземпляра в гіршому випадку, він часто коротший, а значить, його можна "перевірити "в підлінійний час (з урахуванням випадкового доступу до входу як відсортований масив або B-дерево), і, зокрема, у час, менший, ніж потрібно для обчислення такого сертифіката.

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

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

   • $n$$n$
   • Сертифікат на опуклий корпус у двох та трьох вимірах, якщо точки задані у випадковому порядку, потребує стільки ж бітів для кодування, скільки порівнянь для обчислення [FOCS 2009] (інший безсоромний штекер).

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

Сподіваюся, це допомагає ...