Що ми знаємо про достовірно правильні програми?

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

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

Шукаючи в Інтернеті, я знайшов лише проекти, які використовують дуже просту мову програмування або провалили проекти, які намагаються адаптувати сучасні мови програмування. Це призводить мене до мого питання:

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

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

Я бачу переваги вивчення такого класу складності: наприклад, для $ProvableR$ проблема зупинки є вирішуваною (я навіть здогадуюсь $ProvableRE$ визначеною очевидним чином. найбільший клас мов, для яких його можна вирішити). Крім того, я сумніваюся, що ми виключаємо будь-які практично корисні програми: хто буде використовувати програму, коли ви не можете довести, що вона припиняється?

Отже, моє друге питання:

Що ми знаємо про класи складності, які вимагають, щоб їх мови, що містять, мати певні властивості?

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

Сам компілятор Compcert - це програма з підтвердженням коректності (зроблена в Coq), яка гарантує, що якщо вона генерує код для програми, вона буде правильною (стосовно оперативної семантики складання та C, яку використовували дизайнери CompCert). Зусилля для машинної перевірки цих речей досить великі; зазвичай доказ коректності буде розміром від 1х до 100х розмірів програми, яку ви перевіряєте. Написання перевірених машинами програм та доказів - це нова майстерність, яку ви повинні засвоїти - це не математика чи програмування, як зазвичай, хоча це залежить від того, щоб вміти робити як добре. Ви відчуваєте, що починаєте з нуля, як знову початківець програміст.

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

EDIT: Дай Ле попросив детально розробити останній пункт.

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

Але є і деякі теоретичні причини. В основному, ми не знаємо дуже багато способів систематично вигадувати програми, чиї докази коректності дуже довгі. Основним методом є (1) прийняти логіку, в якій ти доводиш правильність, (2) знайти властивість, яка не може бути безпосередньо виражена в цій логіці (доказів узгодженості є типовим джерелом), і (3) знайти програму, чию Доказ коректності покладається на сімейство виразних наслідків невимовної властивості. Оскільки (2) є невимовними, це означає, що доведення кожного виразного наслідку потрібно робити самостійно, що дозволяє підібрати розмір доказу правильності. Як простий приклад, зауважте, що в логіці першого порядку з родительським відношенням ви не можете виразити відношення предків.$k$$k$) виражається для кожного фіксованого . Таким чином, надаючи програмі, яка використовує певну глибину властивості родини (скажімо, 100), ви можете примусити доказ коректності у FOL містити докази цих властивостей у сто разів.$k$

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

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

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

Це не означає, що не було успішних випадків перевірених програм. Я знаю, що є групи, які доводять правильність таких систем, як гіпервізор Microsoft . Пов’язаний випадок - це підтверджений компілятор Microsoft . Але загалом сучасні інструменти потребують значного розвитку (включаючи їх аспекти SE та HCI), перш ніж стати корисними для загальних програмістів (і математиків).

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

На друге запитання я відповів на подібне запитання в блозі Скотта десь тому. В основному, якщо клас складності має хорошу характеристику і є виразно представницьким (тобто це ce), то ми можемо довести, що деяке представлення проблем у класі складності виявляється сумарним у дуже слабких теоріях, що відповідають класу складності. Основна ідея полягає в тому, що суто загальні функції теорії містять усі функції і задачу, яка A C $AC^0$$AC^0$-комплект для класу складності, тому він містить усі проблеми класу складності і може довести сукупність цих програм. Співвідношення між доказом і теорією складності вивчається в доказівній складності, див. С.А. Кука та останню книгу П.Нгуєна " Логічні основи складності доказування ", якщо вас цікавить. ( Проект від 2008 р. Доступний.) Отже, основна відповідь полягає в тому, що для багатьох класів "Доведено C = C".

Це взагалі не вірно, оскільки існують класи семантичної складності, які не мають синтаксичної характеристики, наприклад, загальні обчислювані функції. Якщо під рекурсивним способом ви маєте на увазі загальну рекурсивну функцію, то обидві не є рівними, а набір обчислюваних функцій, які в теорії є загальнодоступними, добре вивчений у літературі теорії доказів і називається доказівно сумарними функціями теорії. Наприклад: суттєво сумарні функції є ϵ 0 -рекурсивними функціями (або еквівалентними функціями в системі Годеля Гольделя T ), а суттєво сумарні функції P A 2 є функцією в системі Жирара F , а сумарні функції$PA$$\epsilon_0$$T$$PA^2$$F$ - примітивні рекурсивні функції, ....$I\Sigma_1$

Але мені не здається, що це значно означає в контексті верифікації програми, оскільки є також програми, які розширюють одну і ту ж функцію, але ми не можемо довести, що обидві програми обчислюють одну і ту ж функцію, тобто програми є рівними, але не навмисно. (Це схоже на "Ранкова зірка" та "Вечірня зірка". Більше того, легко змінити задану суттєво загальну програму, щоб отримати ту, яку теорія не може довести її сукупність.

Я думаю, що два питання пов'язані між собою. Мета - отримати перевірену програму. Перевірені програми означають, що програма задовольняє опису, який є математичним твердженням. Один із способів - написати програму мовою програмування, а потім довести її властивості так, як вона задовольняє опису, що є звичайнішою практикою. Інший варіант - спробувати довести математичне твердження, що описує проблему, за допомогою обмежених засобів, а потім витягнути з неї перевірену програму. Наприклад, якщо ми докажемо в теорії, що відповідає що для будь-якого заданого числа n існує послідовність простих чисел, їх добуток дорівнює n , то ми можемо отримати $P$$n$$n$$P$алгоритм факторизації з доведення. (Є також дослідники, які намагаються максимально автоматизувати перший підхід, але перевірити цікаві нетривіальні властивості програм обчислювально важко і їх неможливо повністю перевірити без помилкових позитивів і негативів.)

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

EDIT: просто хотів би надати акцент на "певній мірі". Це далеко не вирішена проблема, але успіх Coq дає надію, що це не трудна мрія.

Інструмент, який перевіряє правильність програми, іноді називається верифікатором програми. У цьому контексті "правильний" зазвичай означає дві речі: програма ніколи не дає певних результатів (помилка сегментації, помилка NullPointerException тощо) і що програма погоджується із специфікацією.

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

Маючи на увазі ці застереження, рекомендую переглянути перевірку програми Spec # .

У загальному випадку неможливо створити алгоритм, який підтверджує, чи алгоритм еквівалентний специфікації. Це неофіційний доказ:

Практично всі мови програмування закінчені Тьюрінгом. Отже, будь-яка мова, яку вирішує ТМ, також може бути визначена програмою, написаною цією мовою.

Проблема визначення того, чи приймають дві ТМ одну і ту ж мову, відому як $Equivalence/TM$ is undecidable. As a consequence of Turing completeness, the same holds for the programs of the given language. In other words, it is undecidable to know whether the inputs you want your program to accept and the inputs it really does are the same.

Furthermore, $Equivalence/TM$ is not even recursive enumerable. That is because $Non-emptiness/TM$ (whether a TM accepts at least one input) is an acceptable language, since you can iterate over all possible inputs. If the TM is non-empty, eventually you will find a word that is accepted. Therefore $Emptiness/TM$ is unacceptable, otherwise $Emptiness/TM$ would be decidable (which we know it is not). However Emptiness/TM can be reduced to $Equivalence/TM$, therefore $Equivalence/TM$ is also unacceptable. Therefore you can use an algorithm whether or not two machines are not equivalent, but you cannot be sure if they are equivalent, or you haven't given your algorithm enough time.

However, this is only for the general case. It is possible that you can decide whether or not the specifications are equivalent to the program, by solving a more relaxed version of the problem. For example, you might examine only a number of inputs or say that the two programs are equivalent with some uncertainty. This is what software testing is all about.

As for the rest of your questions:

Note: This part has been edited for clarification. It turns out that I did the mistake I was trying to avoid, sorry.

Let $TrueR$ be the collection of languages that we know to be decidable. Of course $TrueR \subseteq R$. One can then prove the following:

$ProvableR = TrueR$. It is easy to see that $ProvableR \subset TrueR$. However, it is also $TrueR \subset ProvableR$ . The proof is very easy: Let $A \epsilon TrueR$ . By definition , in every input $A$ returns either YES or NO. Therefore, $A$ halts on every input. It follows that $A \epsilon ProvableR$ .

Informally , this can be summarized as: You don't know that a language is decidable until you have proven it to be. So if in a formal system you have the knowledge that a language is decidable, this knowledge can also serve as a proof for that. Therefore, you cannot simultaneously have the knowledge that a language is both decidable and it cannot be proven so, these two statements are mutually exclusive.

My final point is that our knowledge is partial and that the only way of studying $R$ is through $ProvableR$. The distinction might make sense in mathematics and we can acknowledge it, but we possess no tools to study it. Since $ProvableR \subset R$ , we are bound to never completely know $R$ in its entirety.

@Kaveh summarizes it best: Provable always means provable in some system/theory and does not coincide with truth in general.

The same holds for any other complexity class: To determine membership you need a proof first. This is why I believe that your second question is too general, since it contains not only complexity theory, but also computation theory as well, depending on the property you want the language to have.

The following classic monograph studies almost exactly your second question:

Hartmanis, J. Feasible computations and provable complexity properties, CBMS-NSF Regional Conference Series in Applied Mathematics, 30. Society for Industrial and Applied Mathematics (SIAM), Philadelphia, Pa., 1978.

For example, he defines the class "F-TIME[T(n)]" (where F is some reasonable formal proof system) to be $\{L(M_i) | T_i(n) \leq T(n) \text{ is provable in F}\}$ (where $M_i$ is the i-th Turing machine in a complete list of TMs, and $T_i(n)$ is the maximum running time of $M_i$ on inputs of length $n$). Let me just highlight a few results relevant to your question - many more can be found in the monograph and references therein:

Cor. 6.4: Let $T(n) \geq n \log(n)$ be a computable function, and let $g(n) \geq 1$ be an unbounded computable function. Then $F$-$TIME[T(n)] \subsetneq TIME[T(n) g(n)]$.

Theorem 6.5: There exist computable monotonically increasing time bounds $T(n)$ for which $F$-$TIME[T(n)] \neq TIME[T(n)]$.

Theorem 6.14: For any computable $T(n) \geq n \log(n)$, $TIME[T(n)] = \{ L(M_i) | \text{F proves} (\exists j)[L(M_j) = L(M_i) \wedge T_j(n) \leq T(n)] \}$.

For space, however, the situation is better controlled:

Theorem 6.9: (1) If $s(n) \geq n$ is space-constructible, then $SPACE[s(n)] = F$-$SPACE[s(n)]$.

(2) If $SPACE[S(n)]=F$-$SPACE[S(n)]$ ($S(n) \geq n$) then there is a space-constructible $s(n)$ such that $SPACE[S(n)]=SPACE[s(n)]$.

The question has to be posed correctly. For example, nobody ever wants to know whether an actual program would complete given infinite memory and some means of accessing it (maybe an operation to move the base address by some number). Turing's theorem is irrelevant to program correctness in any concrete sense and people who cite it as a barrier to program verification are confusing two quite different things. When engineers/programmers talk of program correctness they want to know about finite properties. This is also pretty much true for mathematicians who are interested in whether something is provable. Godel's letter http://vyodaiken.com/2009/08/28/godels-lost-letter/ explains this in some detail.

Namely, it would obviously mean that in spite of the undecidability of the Entscheidungsproblem, the mental work of a mathematician concerning Yes-or-No questions could be completely replaced by a machine. After all, one would simply have to choose the natural number n so large that when the machine does not deliver a result, it makes no sense to think more about the problem.

It may well be infeasible to examine the immense state set of a program executing on an actual computer and detect bad states, there is no theoretical reason why it can't be done. In fact, there has been a lot of progress in this field - for example see http://www.cs.cornell.edu/gomes/papers/SATSolvers-KR-book-draft-07.pdf (thanks to Neil Immerman for telling me about this)

A different and more difficult problem is specifying exactly what properties one wants a program to have in order to be correct.