Updates:
Status: Fixed
Labels: WrongResult
Comment #3 on issue 2443 by asmeurer: Result of subs() is incorrect after
unpickling
http://code.google.com/p/sympy/issues/detail?id=2443
OK, so I see that this behaves as you describe in SymPy 0.6.7. I bisected
it down to this commit:
commit 7458c3ff17d184fc9a0e9e131fb0999f47154233
Author: Chris Smith <[email protected]>
Date: Wed Aug 25 13:20:45 2010 +0545
2039: Mul._eval_subs fixes
Issues: 2110, 2022, 2039
1) ele was being removed from the wrong list (comm_self instead of
comm_final)
which can lead to an element trying to be removed when it is not there:
>>> (a*A*B).subs(a**2*A,1)
.
.
.
ValueError: list.remove(x): x not in list
2) exp and rational powers are not handled when they occur in a Mul the
same
way that they are handled when in isolation:
>>> var('x y')
(x, y)
>>> (x**2*y**(3*x/2)).subs(x*y**(x/2),2)
x**2*y**(3*x/2)
It should have returned 4*y**(x/2).
>>> (x*exp(x*2)).subs(x*exp(x),2)
x*exp(2*x)
It should have been returned 2*exp(x).
3) powers encountered in Mul's args could be standardized with powsimp
in breakup so (x**(2*y))**3 would get stored as x**y 6 times rather than
x**(2*y) three times. powsimp is too comprehensive/slow for this change
(and is currently makes the change incorrectly) so a new powdenest
function
was added to simplify.py
4) The manner in which unmatched terms were being handled to make
any replacements in them could lead to infinite recursion in a case like
>>> ((1+A*B)*A*B).subs(A*B, A*B*C)
.
.
.
hangs
5) The recursive nature of the existing Mul._eval_subs makes the
handling of
rational powers difficult, (after removing one x**(y/2) other x**(y/2)
might
combine to become x**y so the routine was re-written. It is now shorter
and
of similar efficiency.
6) Doing a substitution on Mul() rather than the terms of Mul
led to an infinite recursion problem. This issue only arose
when doing a test in py 2.6.6 and 2.7 (3.0 was not tested):
N(fibonacci(1000) - (GoldenRatio)**1000/sqrt(5), strict=True)
No test for this expression was added since it is python-version
dependent, but testing in 2.7 no longer generates the recursion error.
The initial fix was to replace the substitution of lines that had
a substitution on a Mul with the version offered in the inline
comments,
e.g.
return Mul(coeff_self/coeff_old, new,
- Mul(*comms_final)._eval_subs(old,new))
+ Mul(*[c._eval_subs(old,new) for c in comms_final]))
but this led to problems with noncommutative expressions.
*******
The above issues have been addressed and in addition, substitution can
take place if the leading coefficient on old is extractable from the
leading
coefficient of self (both being Rational).
The ordering of code-printed factors changed and tests were updated
acccordingly.
In order to handle powers better (and in anticipation of changes
upcoming
for solve) a function 'powdenest' was added. It, like logcombine, has an
option to force symbolic behavior y even for symbols that haven't been
given assumptions. The key word to use is 'force=True'; the corresonding
word in logcombine was also changed to force=True.
So either wait for the next release (it should be coming soon), or use the
latest development branch (see GettingTheBleedingEdge).
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
