Sorry for late reply. However i had mentioned in my second post as an edit
that 'x' is with assumption 'real=True'.
But i now understand that "operation i suggested" makes the expression
more of complex. Rather than simplifying it.
On Tuesday, May 19, 2015 at 9:36:30 PM UTC+5:30, Aaron Meurer
Nobody could tell how chop works?
On Tuesday, May 5, 2015 at 11:41:24 AM UTC+3, Paul Royik wrote:
>
> expr
> =
> 2682469501914725726236807146020965585039500052171867725591732162347*exp(-60)/48648670709168952944186714683693506574127
>
> N(expr) outputs 0.482830727370627
> but
> N(expr, chop=True)
I'm guessing chop chops some intermediate expression that is smaller
than the cutoff in this case. It probably should be considered a bug.
Aaron Meurer
On Thu, May 21, 2015 at 8:53 AM, Paul Royik wrote:
> Nobody could tell how chop works?
>
> On Tuesday, May 5, 2015 at 11:41:24 AM UTC+3, Paul Ro
OK.
Thank you.
Could you move it to issues?
On Thursday, May 21, 2015 at 6:45:41 PM UTC+3, Aaron Meurer wrote:
>
> I'm guessing chop chops some intermediate expression that is smaller
> than the cutoff in this case. It probably should be considered a bug.
>
> Aaron Meurer
>
> On Thu, May 21, 20
Hi,
My sympy-foo is a bit rusty now, but I think you would have to implement
this in core.Pow to get automatic simplification of that expression.
However, there may be good reasons to avoid putting all kinds of special
cases into the core module.
The terms should vanish when you apply Wick's th
