Почему оптимизаторы λ-исчисления способны вычислять большие модульные экспоненции без формул?

Ответ 1

Явление исходит из количества общих этапов бета-восстановления, которые могут быть резко различны в ленивой оценке в стиле Хаскелла (или обычном call-by-value, что не так уж и далеко в этом отношении) и в Vuillemin-Lévy -Lamping-Kathail-Asperti-Guerrini- (и др.) "Оптимальная" оценка. Это общая функция, полностью независимая от арифметических формул, которые вы можете использовать в этом конкретном примере.

Обмен означает наличие вашего лямбда-термина, в котором один "node" может описывать несколько аналогичных частей фактического лямбда-термина, который вы представляете. Например, вы можете представить термин

\x. x ((\y.y)a) ((\y.y)a)

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

Мемонирование в стиле Хаскеля реализует совместное использование полных субтерм. Этот уровень обмена может быть представлен направленными ациклическими графами. Оптимальное разделение не имеет этого ограничения: оно также может делиться "частичными" подтермиями, что может означать циклы в представлении графика.

Чтобы увидеть разницу между этими двумя уровнями совместного использования, рассмотрите термин

\x. (\z.z) ((\z.z) x)

Если ваш общий доступ ограничен полными субтерминами, как это имеет место в Haskell, у вас может быть только одно вхождение \z.z, но два бета-редекса здесь будут отличаться: один - (\z.z) x, а другой (\z.z) ((\z.z) x), и поскольку они не равны, они не могут быть разделены. Если разрешено разделение частичных субтерм, тогда становится возможным разделять частичный термин (\z.z) [] (это не просто функция \z.z, а "функция \z.z, примененная к чему-то), которая оценивается за один шаг до просто что-то, независимо от этого аргумента. Следовательно, вы можете иметь график, в котором только один node представляет два приложения \z.z для двух различных аргументов и в которых эти два приложения могут быть уменьшены всего за один шаг. на этом node есть цикл, поскольку аргумент" первого вхождения "является именно" вторым вхождением". Наконец, при оптимальном совместном использовании вы можете перейти от (графика, представляющего) \x. (\z.z) ((\z.z) x)) к (графику, представляющему) результат \x.x всего за один шаг бета-редукции (плюс некоторый бухгалтерский учет). Это в основном то, что происходит в вашем оптимальном оценщике (и представление графика также предотвращает взрыв пространства).

Для слегка расширенных объяснений вы можете посмотреть на бумагу "Слабая оптимизация" и "Значение общего доступа" (вас интересует введение и раздел 4.1, а может быть, некоторые из библиографических указателей в конце).

Возвращаясь к вашему примеру, кодирование арифметических функций, работающих с целыми числами Церкви, является одной из "хорошо известных" шахт примеров, где оптимальные оценщики могут работать лучше, чем обычные языки (в этом предложении хорошо известно, что это означает, что некоторые специалисты знают об этих примерах). Для более таких примеров взгляните на статью Безопасные операторы: скобки закрыты навсегда от Asperti и Chroboczek (и, кстати, вы найдете здесь интересные лямбда-термины, которые не являются EAL-типами, поэтому Im поощряю вас взглянуть на оракулы, начиная с этой работы Asperti/Chroboczek).

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

Ответ 2

Это не anwser, но это предложение о том, где вы можете начать искать.

Существует тривиальный способ вычисления модульных выражений в небольшом пространстве, в частности, путем перезаписи

(a * x ^ y) % z

а

(((a * x) % z) * x ^ (y - 1)) % z

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

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