Какова цель абстрактной интерпретации в языках программирования?

Сейчас я пытаюсь лучше понять, что такое «абстрактная интерпретация» в языках программирования. Я нашел хорошую главу книги, которая объясняет идею расширения области с помощью наименее фиксированного элемента, четырех аксиом, которые дают фиксированную точку для непрерывной функции, и так далее. Я понимаю эти технические детали (хотя я не совсем уверен, что именно означает «абстрактная интерпретация» во всей этой схеме).

Что я не уверен в том, что мотивирует использование абстрактной интерпретации? Это просто определение фиксированных точек для вычислимых функций? Является ли основной мотивацией наличие рекурсии в большинстве языков программирования?

Также был бы рад получить краткий обзор высокого уровня, который технически достаточно глубок для тех, кто имеет степень в области компьютерных наук. Я нахожу страницу Википедии довольно тревожной.

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

Вычислительная сложность как мотивация

Давайте начнем с решения проблем, решения которых имеют такую ​​структуру:

Часто на процедуре существует нижняя граница NP-харда. Проверка семантических свойств программ даже неразрешима. Что мы можем сделать?

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

1. Что значит формально решить некоторые, но не все проблемные случаи?
2. Каково примерное решение проблемы решения?

Абстрактная идея интерпретации 1: изменить постановку задачи

Для меня главное понимание абстрактной интерпретации состоит в том, чтобы изменить формулировку проблемы так, чтобы вместо того, чтобы спрашивать ответ « да» или «нет» , мы спрашивали ответ « да» / «нет» / «возможно») .

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

Эта идея не ограничивается решением проблем. Рассмотрим эти проблемы, касающиеся программ.

1. Какие строки кода в программе не работают (никогда не будут выполнены)?
2. Какие переменные в программе имеют постоянные значения?
3. Какие утверждения в программе нарушены?

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

1. Что такое набор строк кода, который мертв?
2. Что такое набор переменных в программе, которые имеют постоянные значения?
3. Что такое набор утверждений в программе, который не нарушается?

Производимые наборы не обязательно должны быть самыми большими. Эта идея чрезвычайно общая и относится к проблемам, которые имеют мало общего с программным анализом.

1. Вместо добавления $m$ а также $n$мы можем попросить диапазон $[a,b]$ в котором лежит сумма.
2. Вместо умножения $m$ по $n$ мы можем попросить $k$ биты результата (конкретные, общие примеры - знак или бит четности).
3. Вместо того, чтобы запрашивать удовлетворяющие назначения в формуле, мы можем попросить набор, который содержит удовлетворяющие назначения.

Обратите внимание, что мы не только изменили проблему, но и строго обобщили ее, потому что решение исходной проблемы все еще является решением измененной проблемы. Большой без ответа вопрос сейчас: как мы можем найти приблизительное решение?

Абстрактная идея интерпретации 2: фиксированная характеристика исходных решений

Вторая большая идея состоит в том, чтобы заметить, что множество решений многих задач имеет характеристику неподвижной точки в решетке возможных решений. В качестве примера предположим, что у вас есть граф, и вы хотите знать, есть ли вершина$t$ достижимо из вершины $s$, Мы можем разбить это на поиск множества$\mathit{Reach}(s)$ всех вершин, достижимых из $s$ а затем проверить, если $t$находится в этом наборе. Мы можем далее наблюдать, что$\mathit{Reach}(s)$ является наименьшим решением уравнения:

$X = \{s\} \cup \{ w ~|~ v \text{ is in } X \text{ and } (v,w) \text{ is an edge}\}$

Значение характеристики с фиксированной точкой заключается в том, что точное решение можно рассматривать как предел ряда приближений. В этом примере$n$-ым элементом ряда является множество вершин графа, достижимых в $n$ шаги от $s$ и приближение является подмножеством этих вершин.

Характеристика с фиксированной точкой является проектным решением. Существует множество различных характеристик множества решений. Каждый из них может иметь разные преимущества. В случае языков программирования у нас больше структуры, чем просто работа с графом. Уравнения с фиксированной точкой, о которых мы заботимся, могут быть определены по индукции в структуре входной программы. Эта идея не специфична для программ. Применяя абстрактную интерпретацию к элементам структурированного языка, таким как грамматика, логическая формула, программа, арифметическое выражение и т. Д., Мы можем определять фиксированные точки путем наведения на структуру некоторого синтаксического объекта.

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

Абстрактная идея интерпретации 3: приближение с фиксированной точкой

Вместо вычисления фиксированной точки функции $F$ в решетке $L$мы можем вычислить фиксированную точку другой функции $G$ в решетке $M$, При условии соблюдения определенных условий, касающихся$M$ в $L$решение, вычисленное в $M$ гарантированно является приближением решения в $L$, Это один из основополагающих результатов абстрактной интерпретации, обычно называемый теоремой о переносе неподвижной точки . Условие надежности задается либо связями Галуа, либо более слабыми настройками, включающими функции абстракции или конкретизации, или отношениями разумности.

Теорема о фиксированной точке переноса гарантирует, что вам не нужно доказывать, что вы вычисляете звуковое приближение каждый раз, когда разрабатываете приблизительный анализ. Вам нужно только доказать, что решетки$L$ (содержащий оригинальные решения) и $M$ (содержащий приближения) и функции $F$ а также $G$удовлетворить определенные ограничения. Это большая победа, если вы разработчик анализа, и вы заботитесь о надежности.

Вы можете найти интуитивное представление о передаче с фиксированной точкой проницательным. Мы можем рассматривать неподвижную точку как предел (возможно, трансфинитной) цепочки элементов. Вычисление приближенных решений сводится к аппроксимации этого предела, что мы можем сделать путем аппроксимации элементов цепочки.

Понятие приближения зависит от приложения. Если вы используете график доступности для планирования поездки, вы можете принять приближение, которое скажет вам, что между$s$ а также $t$ даже если есть путь, но вы не будете счастливы, если алгоритм говорит, что путь от $s$ в $t$ там, где нет пути.

Абстрактная идея интерпретации 4: Алгоритмы аппроксимации с фиксированной точкой

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

Резюме

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

Вычисление приближений к задачам, у которых нет естественной метрики, - это искусство, которое постоянно развивается и совершенствуется практиками. Абстрактная интерпретация - одна математическая теория для науки, стоящей за этим искусством.

Ссылки Есть несколько хороших руководств по абстрактной интерпретации, которые вы можете прочитать.

1. Случайное введение в абстрактную интерпретацию , Патрик Кузо (совместная работа с Радхией Кузо), семинар по системной биологии и формальным методам (SBFM'12)
2. Небольшое введение в формальную верификацию компьютерных систем с помощью абстрактной интерпретации , Патрик и Радия Кузо, Летняя школа Марктобердорфа 2010.
3. Лекция 13: Абстракция, часть I , Патрик Кузо, Абстрактная интерпретация, MIT Course.
4. Введение в абстрактную интерпретацию , Самсон Абрамский и Крис Ханкин, Абстрактная интерпретация декларативных языков, 1987.
5. Абстрактная интерпретация и применение к логическим программам , Patrick and Radhia Cousot, 1992. Первые два раздела имеют общий обзор высокого уровня с несколькими примерами.

Я согласен с тем, что часто бывает трудно извлечь главное из всех этих деталей. (На самом деле, моя большая проблема с каждой трактовкой абстрактной интерпретации, которую я видел, заключается в том, что они представляют так много механизмов, не мотивируя их.)

Вот как я об этом думаю:

Абстрактная интерпретация - это запуск программ, приблизительно, на больших наборах входов одновременно.

Это не покрывает все, но в целом хорошо.

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

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

Вы даже не можете напрямую представить набор всех положительных чисел. Вместо этого вам нужна абстракция этого набора. Вы также должны абстрагироваться от отрицательных чисел и нуля. Вы в конечном итоге с семейством конечных абстрактных множеств$\{neg,zero,pos\}$, которые представляют собой конкретные наборы$\{\{...,-2,-1\},\{0\},\{1,2,...\}\}$,

Теперь вы можете придумать правила, такие как «добавление двух положительных чисел приводит к положительному числу» или $add : pos \times pos \to pos$, Придумайте правила для каждого из ваших языковых примитивов, и вы можете притворяться, что оцениваете арифметические выражения на больших наборах входных данных одновременно.

Конечно, правило «добавления положительного и отрицательного числа» доставит вам неприятности, потому что подобные добавления могут возвращать что угодно. Здесь вам поможет абстрактная структура интерпретации: она говорит, что вы должны вернуть максимально приближенное звуковое приближение. Если ваши правила верны, и они говорят, что сложение возвращает что-то в абстрактном наборе, любая конкретная оценка должна возвращать число в соответствующем конкретном наборе. Например,$add : pos \times pos \to pos$ Правило звучит, если $add(a,b)$ положительно для каждого положительного $a$ а также $b$, Также,$pos \times neg \to (pos \sqcup zero \sqcup neg)$ это звук, где "$\sqcup$"это операция объединения ваших абстрактных множеств.

Я полагаю, что даже самый молодой исследователь PL мог бы написать такую ​​абстрактную интерпретацию днем. Это на самом деле не так сложно, и вы должны попробовать это, прежде чем читать гораздо больше, чтобы почувствовать основы. Пока вы это делаете, вы обнаружите, что ваши абстрактные множества нуждаются в некотором понятии пересечения (обозначается как «$\sqcap$") и подмножество (обозначается"$\sqsubseteq$"). Они должны соответствовать конкретному пересечению и подмножеству.

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

Если вы хотите работать с языком с циклами или рекурсией, ваши программы могут не завершиться, поэтому вам понадобится $\bot$значение для представления нетерминации. Вам нужно будет «вычислить» (в математическом смысле) конкретные функции как точки фиксации и аналогичным образом вычислить абстрактные функции. Если у вас есть функции более высокого порядка, вы обнаружите, что типичный топологический механизм не обрабатывает их вообще (приложение более высокого порядка обычно не является непрерывным), и вам нужны домены Скотта.

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