math cas
Напишу хоть сюда, чтоб где-то было. Требования к правильной современной CAS (computer algebra system):
R1. Должна максимально прозрачно встраиваться в язык общего назначения, желательно (относительно) известный.
Чтобы можно было например спросить что-то у юзера, пощитать от этого интеграл, результат послать куда-то по сети, прочитать что-то из БД, нарисовать окошко итд. Не требуя при этом от пользователя изучать новый фреймворк рисования окошек. Желательно, чтобы этот ЯП мог компилироваться в нативный код с оптимизациями.
Лучше всего, видимо, чтобы это был EDSL к существующему ЯП.
R2. Ядро должно оперировать абстрактными терминами, типа «символ», «выражение» итд, а не конкретными «число», «поле». Такие вещи, как поля или вектора, должны быть в стандартной библиотеке, должна быть возможность их убрать или заменить без переписывания ядра.
R3. Строгая статическая типизация с широко развитым полиморфизмом. Желательно с выводом типов.
Рассмотрение с точки зрения теории типов даже простейших математических понятий типа «поле остатков по модулю 7» приводит к выводу, что нужны зависимые типы. «X имеет тип PrimeField(7)», «PrimeField(7) относится к классу Field».
R4. Возможность строгих рассуждений над кодом. Желательно, чтобы сравнительно легко было построить математически строгое доказательство корректности алгоритма.
Чтобы, например, получив от системы ответ «интеграл от этого равен тому-то», не сомневаться «а учла ли система случай когда в z0 особая точка». В идеале, пользователь должен иметь возможность уверенно копипастить ответы системы в статьи/диссертации.
В сочетании с предыдущим — по всей видимости, единственный вариант — использование зависимых типов вместе с активным использованием Curry-Horward isomorphism для доказательств.
R5. Развитый pattern matching, желательно включая нелинейный.
Нелинейный — это когда в паттерне одна переменная может встречаться несколько раз, и матчится только тогда, когда на этих местах действительно стоит одно и то же. Simplify(x/x) = 1.
Многие математические алгоритмы изначально формулируются в терминах pattern matching. Начиная хотя бы с правил дифференцирования.
Как-то так. Такие очевидные требования, как кроссплатформенность или функция вывода в TeX в стандартной библиотеке, вроде, не требуют обсуждения.
Чего
точно не надо в современной CAS по сравнению с исторически существующими:
U1. Самостийная (интегрированная в ядро) система рисования графиков. Существующие standalone программы и библиотеки для этого (gnuplot, matplotlib итд) далеко переплюнули встроенные возможности CAS. Достаточно обеспечить возможность интеграции с существующими отдельными решениями.
U2. Встроенный, а то и неотключаемый, развитый GUI. Желателен REPL и возможность интеграции с решениями типа TeXmacs или Jupyter, и то на первых порах не обязательно. По минимуму это может быть консольная программа типа компилятора, которую натравливаем на файл с кодом и получаем ответы на stdout. Или получаем бинарник, который при запуске печатает ответы.
