Опа...

Ну классическая физика - законы ньютона, лагранжиан, гамильтониан (из общеизвестных). Квантовая - координатное-импульсное, интегралы по траекториям/волновые функции (можно ещё стохастические диффуры использовать)

да. и мне интересно, как они обходят данные проблемы

Насколько я понимаю, массы их игнорируют по незнанию.

Но это, в основном, интерфейс «человек-компьютер».

В clang format - дают пользователю отключить форматирование (с помощью комментариев) в проблемных местах, типа тех же матриц

Это костыль. Наверняка можно без захламления кода что-то сделать.

Собственно, кто эти комментарии будет расставлять?

> Наверняка можно без захламления кода что-то сделать.
С матрицами можно наверное распознавать когда в расположенных рядом строках можно найти общую для этих строк последовательность столбцов, в каждом из которых начинается токен одного типа. Понять в общем виде, когда пользователь хотел добиться какого-то специального форматирования, а когда нет - задача из "класса" AI-complete

По-сути, всё-таки, ML-complete. Или даже statistics-complete. 😉

AI дороже выглядит

А в этом чате есть инвесторы? 😂

> Собственно, кто эти комментарии будет расставлять?
Если какая-нибудь команда сильно захочет, она может у себя делать принудительную проверку что любой коммит не меняется после прогона через clang-format (или другой инструмент) с заданным набором опций и не давать коммитить без этого. Тогда разработчики будут сами расставлять комментарии.

Практика показывает, что от балды выбирается стиль, а дальше кодобаза прогоняется через него «мальчиком-дизайнером».

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

Просто нужны некоторые исследования и теория.

Кроме того, интересно проносить форматирование вниз по истории git/svn. Это алгебраическая задача .

Теорию мы уже обсуждали https://t.me/CompilerDev/45566

> Просто нужны некоторые исследования и теория.
Кстати, ещё одна сложность с C/C++ AST ещё в том, что есть макросы и код надо форматировать до их раскрытия, а не после.
Если бы я работал над такой задачей (форматирование по AST), то наверное бы обходил  узлы AST и смотрел бы какому узлу какой участок исходного кода соответствует. Если узел лежит внутри раскрытого макроса, то заменял бы соответствующее поддерево на псевдо-узел "вызов макроса". Ещё надо не забывать про комментарии, лишние (с точки зрения AST) '\n' и т.п. Про эти элементы я бы наверное тоже как-то пытался угадать к какому узлу AST они относятся (следующему или предыдущему лексически) и считал бы частью узла.

> Теорию мы уже обсуждали https://t.me/CompilerDev/45566
Там вроде речь шла про pretty print

Выше речь шла о форматированном выводе кода на основе AST. Можно показать, что эта задача чрезвычайно сложна, а можно — показать, что ее давно и успешно решают. Но мой контекст — форматирование автоматически сгенерированного кода.

> Выше речь шла о форматированном выводе кода наоснове AST
Не совсем

Оно должно учитывать не только AST, но и исходное форматирование/комментарии/проч.

да, совершенно верно