Симп баг?Даже с `valu = False` уравнения автоматически обрабатываются - PullRequest
0 голосов
/ 25 февраля 2019

Рассмотрим следующий симпози-код:

from sympy import Add
from sympy.abc import x

t1 = 2+2*x
t2 = x
myeq = sp.UnevaluatedExpr(Add(sp.UnevaluatedExpr(t1), sp.UnevaluatedExpr(t2), evaluate=False))

# BUG! Will print: x + 2*x + 2
# Yet it should print: 2+2*x+x
print(myeq)

Этот фрагмент кода был адаптирован из этого ответа.Там термины проще, поэтому Add сохранил порядок.Но как я могу заставить Add сохранить порядок и в этом случае?

(Примечание: если мы изменим условия на t1=x и t2=x**2, мой подход с использованием sp.UnevaluatedExpr работает, ноОригинальный ответ, который не имел этих терминов, не имеет. Увы, для моего конкретного случая, даже не используя sp.UnevaluatedExpr работает.)

1 Ответ

0 голосов
/ 25 февраля 2019

Это не ошибка ...

... но больше отсутствует функция.Все это документировано.

Вот что SymPy подразумевает под неоцененным .

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

В вашем примере термины 2*x и x не были упрощены, как ожидается.

Порядок ввода

Вы видите, что SymPy не сохраняет порядок, в котором вы вводите свои термины.Это задокументировано в разделе дерева выражений .

Аргументы коммутативных операций Add и Mul хранятся в произвольном (но последовательном!) Порядке, которыйне зависит от введенного порядка.

Это не должно быть проблемой, поскольку Add и Mul являются коммутативными.

Хотя, если по какой-то причине вы хотите сохранитьпорядок ввода из-за некоммутативности умножения, вы можете сделать это.

В SymPy вы можете создавать некоммутативные символы, используя Symbol('A', commutative=False), и порядок умножения для некоммутативных символов сохраняется тем жев качестве входных данных)

На данный момент не существует некоммутативного сложения.

...