1

In this answer it is explained how to avoid args to be sorted in SymPy classes like Mul, Add and so on.

For a new created class like this one explained here it can go to the right hand side when multiplied by a sympy.core.numbers.Float, sympy.core.numbers.Pi or sympy.core.numbers.Integer, for example, giving:

print D(x) * 1.
1.0*D(x)

The original expression gives 0. when evaluated, while the new one gives D(x).

In order for this differential operator to work properly, it must stay on the left hand side:

print D(x) * 1.
D(x)*1.0

Is there any hidden parameter, like _op_priority for changing __mul__() priority, that tells SymPy the type that stays more to the left or to the right?

Community
  • 1
  • 1
Saullo G. P. Castro
  • 56,802
  • 26
  • 179
  • 234
  • 1
    The question is ok on its own, but if you are using it to create a differential operator object you are probably doing it the wrong way. First of all, using multiplication for differential operators is an inconsistent abuse of notation. In addition such an approach can not clearly represent nested differential operators or sums of constants and differential operators, etc. Moreover differential operators are already implemented in the `diffgeom` module. – Krastanov Jun 05 '13 at 15:01
  • thank you by the comment! I've experienced many issues using this differential opperator, but it's working so far. Do you know how to force a given class to stay on the left/right side in SymPy? – Saullo G. P. Castro Jun 05 '13 at 15:19
  • 1
    I do not know enough details to write this as an answer, but you can try to use `commutative=False`. I really dislike this approach and hope that in some future version of sympy this will be removed (there are no such plans), but if you know what you are doing go on and try it. – Krastanov Jun 05 '13 at 15:27
  • What do you mean by "left side" and "right side"? – asmeurer Jun 05 '13 at 16:19
  • @asmeurer I updated the question. Please, let me know if you have any other question... – Saullo G. P. Castro Jun 05 '13 at 16:48

1 Answers1

1

Multiplication by a Mul does not work the way you expect it to.

First off, the printing order has nothing to do with anything. If that's all you care about, you can change it by modifying the printer.

You should instead look at the object's .args. But even here, this does not matter. When you multiply something by a multiplication, it does not "apply" each multiplication in the order it is seen. Rather, it creates a new Mul object with all the args combined (to be sure, in the commutative=False case, the args are kept in order). Mul does not call any special submethods on these objects. This is a feature we want (see https://code.google.com/p/sympy/issues/detail?q=1941&id=1941 and https://github.com/sympy/sympy/wiki/Canonicalization), but for now, it is not done.

asmeurer
  • 86,894
  • 26
  • 169
  • 240