может и в символьные вычисления, и в нативный код?
https://arxiv.org/abs/2008.05166 — это описание проблем. Решение в компиляторе -- это тренд с использованием "языка" mDAE вместо ODE для физического моделирования похож на создание разных языков программирования для решения expression problem в самой computer science (https://en.wikipedia.org/wiki/Expression_problem, https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions, объяснение "на пальцах" https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/). Суть этой expression problem ровно в том же: разработка библиотек универсальных вычислительных элементов требует от языков программирования и реализующих их компиляторов возможности добавлять новые объекты для старых операций и новые операции для старых объектов, чтобы не нужно было переписывать весь код программы. В mDAE против ODE так же, только мы протягиваем обсуждение программных объектов и операций до моделируемых физических сущностей: или ты делаешь язык, на котором разные функциональные объекты описываются разными наборами уравнений, и просто добавляешь эти модели друг ко другу, или в языке у тебя такой возможности нет. Если не решил эту "model expression problem", то тебе нельзя сделать стандартные библиотеки, оформляющие стандартные поведения функциональных объектов. Знания моделей становятся плохо переносимыми между моделями, модели плохо модифицируемыми -- каждый раз при внесении изменений нужно переписывать и перекомпилировать всю модель. (Это я просто из поста https://ailev.livejournal.com/1549559.html абзац переписал ))) Можно добавить, что это всё изводы DDD — domain driven design. Для каждого концепта "из жизни" должен быть похоже ведущий себя концепт в программе (а для этого — язык их задания, и компилятор должен поддерживать "аддидивность", "просто добавь три строчки для нового концепта куда-нибудь снизу, и всё заработает").
Продрался я через эту книжку по первой ссылке. Там нет ничего про expression problem. Что там есть - так это про необходимость выполнять ПЕРЕД компиляцией - символьные вычисления, которые могут включать проверку и отказ от моделей DAE, выбор подходящих моделей для симуляции, определять условия рестартов для смены режима, и только ПОСЛЕ всего этого - генерировать соответствующий код симуляции. В большинстве языков это потребует отдельной программы для генерации кода и дополнительного шага сборки. Почему удобнее на Julia? Во-первых, можно выполнять произвольный код внутри макроса (перед компиляцией), во-вторых, доступен обширный список математических библиотек. Т.е. это больше про two-language problem или даже про свертку пайплайна разработки (один инструмент вместо двух). Ну и пара следствий из этого: во-первых, перед компиляцией можно обучить модельку на данных, потом сгенерировать код по параметрам модели, получить результаты симуляции, и во-вторых, можно результаты опять подать их на вход для обучения. То есть, цикл замкнулся внутри одного языка.
Да, но я вот тут развернул чуть больше про следствие expression problem: невозможность сделать универсальный алгоритм и поэтому необходимость всё время досыпать алгоритмов и структур данных в уже работающую систему — https://ailev.livejournal.com/1709815.html То есть общее впечатление, что нет одной фичи, которая решает все проблемы — есть некоторый заход на поддержку универсальности, поддержку развития в языке.
Обсуждают сегодня