Re: [sympy] Not performing simplification in scalar multiplication?

[Chris Smith]

On Fri, Feb 15, 2013 at 3:35 AM, Johan Hake <johan...@gmail.com> wrote:
> Hello!
>
> First thanks for a wonderful toolkit!
>
> Second stupid questions and it might have been answered previously. Is it
> possible to not perform a scalar multiplication a la:
>
> from sympy import *
> s = Symbol("s")
> expr=(2.+s)*5
>
> without simplifying the expr to 5*s + 10.0?
>
> I use sympy to generate code and I would like the original expression
> instead of the simplified.
>
> Is this at all possible?
>

You can use Mul(5, 2+s, evaluate=False).

[Aaron Meurer]

Also take a look at
http://code.google.com/p/sympy/issues/detail?id=1497. This is
something that we would like to disable by default, but we haven't
fixed it yet (it will require a bit of work, because a lot of code
implicitly relies on this behavior).

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Johan Hake]

Thanks both of you!

Not sure I will be able to use Mul(..., evaluate=False) as I am executing math code written in sympy. Having to rewrite the math using Mul would clutter my code. When I try to turn of all evaluation by changing the default argument to AssocOp to evaluate=False, I get recursion error when printing some of the expressions.

Also applying the fixes as suggested by the two commits in the branch linked to in issue1497, did not do anything to the problem. 

It looks like it is a "feature" people want to get rid of, but it takes some refactoring, as existing tests and code rely on it... 

At least there is one more user which would benefit from it being removed :)

Johan

[Aaron Meurer]

On Feb 21, 2013, at 6:13 AM, Johan Hake <johan...@gmail.com> wrote:

Thanks both of you!

Not sure I will be able to use Mul(..., evaluate=False) as I am executing math code written in sympy. Having to rewrite the math using Mul would clutter my code. When I try to turn of all evaluation by changing the default argument to AssocOp to evaluate=False, I get recursion error when printing some of the expressions.

That's doing too much. That will disable x*x => x**2 or even x - x => 0. 

Also applying the fixes as suggested by the two commits in the branch linked to in issue1497, did not do anything to the problem. 

Just dig through Mul.flatten and figure out where it is happening. The code is a little complicated, but it is well commented. 

Aaron Meurer

[Chris Smith]

On Thu, Feb 21, 2013 at 9:02 PM, Aaron Meurer <asme...@gmail.com> wrote:
> On Feb 21, 2013, at 6:13 AM, Johan Hake <johan...@gmail.com> wrote:
>
> Thanks both of you!
>
> Not sure I will be able to use Mul(..., evaluate=False) as I am executing
> math code written in sympy. Having to rewrite the math using Mul would
> clutter my code. When I try to turn of all evaluation by changing the
> default argument to AssocOp to evaluate=False, I get recursion error when
> printing some of the expressions.
>
>
> That's doing too much. That will disable x*x => x**2 or even x - x => 0.
>
>
> Also applying the fixes as suggested by the two commits in the branch linked
> to in issue1497, did not do anything to the problem.
>
>
> Just dig through Mul.flatten and figure out where it is happening. The code
> is a little complicated, but it is well commented.
>

Line 512 of core/mul.py, right after "# we are done".

[Johan Hake]

> Just dig through Mul.flatten and figure out where it is happening. The code 
> is a little complicated, but it is well commented.

He, he I have seen smaller methods ;) Will see what I can find.

> Line 512 of core/mul.py, right after "# we are done". 

I have already tried outcommenting the following lines, as that was what was suggested in a sympy branch trying to address this issue. However, that did not do the trick.

Johan

[Johan Hake]

It looks like your (Chris) commit 3e835b50 added some stuff in flatten for both mul and add which causes this behavior.

Outcommenting this "fixes" the flattening.

Johan

[Chris Smith]

On Fri, Feb 22, 2013 at 1:43 AM, Johan Hake <johan...@gmail.com> wrote:
> It looks like your (Chris) commit 3e835b50 added some stuff in flatten for
> both mul and add which causes this behavior.

Oh yes...that's probably the special handling of a Number argument
right at the outset rather than waiting for the whole flatten routine.