If you're working with branch cuts in SymPy, you should be aware of the very useful exp_polar() function, as well as the related polar_lift, periodic_argument, and principal_branch.
The basic reason that this is not true is that x**y**z != x**(y*z) for all x, y, and z, and in particular, for z == 1/y. It is true if x >= 0 or if z is an integer (those are necessary, not sufficient conditions). If you haven't studied complex variables, just remember two important things: - x**y = exp(y*log(x)) (by definition) - exp(x) == exp(x + 2*pi*I*n) for any integer n >From that (and maybe a little understanding of what log(x) means for complex x) you can figure out these thing. For instance, x**y**z is exp(z*log(exp(y*log(x))). If we "cancel" the log and exp, we get exp(z*y*log(x)), which is x**(y*z). But log(exp(x)) != exp(x) in general because of the second point, log(exp(x)) == log(exp(x + 2*pi*I*n)). The complex log is multivalued, but we pick the value that has complex argument in the range (-pi, pi], which gives us a unique integer n for each complex x such that log(exp(x + 2*pi*n)) == x. I'll leave it as an exercise to you to combine these and get a sufficient condition for x**y**z to equal x**(y*z). You may also be interested in my blog post about a similar problem http://asmeurersympy.wordpress.com/2013/03/03/when-does-xlogy-ylogx/. Finally, I should point out that if we are interested in getting *all* the solutions, then z**w = y -> y**(1/w) is no good anyway. If w is an integer, there are w solutions (corresponding to the w primitive roots of unity). Aaron Meurer On Tue, Mar 18, 2014 at 11:20 AM, Harsh Gupta <[email protected]> wrote: > We will have to be "very" careful while rewriting the solvers. I just came > across another of Professor Fateman's paper which describes why the solution > of z**w == y for z isn't simply y**(1/w). > > http://www.cs.berkeley.edu/~fateman/papers/y=z2w.pdf > > Sadly we doing it wrong. > > We are also wrongly simplifying y - (y**(1/(1 + I)))**(1 + I) as 0. > > In [58]: f > > Out[58]: y - (y**(1/(1 + I)))**(1 + I) > > > In [59]: simplify(f) > > Out[59]: 0 > > > > > > On 17 March 2014 16:39, Harsh Gupta <[email protected]> wrote: >> >> >> We won't be able to support such output with our new output API >> >> assert solve(x - exp(x), x, implicit=True) == [exp(x)] >> >> > How is this implemented? >> >> I read the code and it appears. >> Things like exp(x) are replaced by dummy symbols and then solve is allowed >> to run on it. After the solution is obtained the dummy symbols are replaced >> back with their original values. >> >> >> >> On 17 March 2014 05:53, Aaron Meurer <[email protected]> wrote: >>> >>> Looking through my notes >>> (https://github.com/sympy/sympy/wiki/assumptions_handlers, pardon the >>> formatting; it looks better in emacs), I see that most of the wrong >>> results I saw were not in the "core" facts, like positive or real >>> (other than the ones you probably already knew about with infinities >>> https://github.com/sympy/sympy/issues/5976). It looks like most of the >>> blatant wrong results that I found were in ntheory (and yes, I am >>> guilty of not ever opening issues for these things) >>> >>> In [2]: ask(Q.prime(x*y), Q.integer(x)&Q.integer(y)) >>> Out[2]: False >>> >>> In [3]: ask(Q.prime(x**y), Q.integer(x)&Q.integer(y)) >>> Out[3]: False >>> >>> In [6]: ask(Q.integer(abs(x)), ~Q.integer(x)) >>> Out[6]: False >>> >>> I leave it as an exercise to the reader why each of the above is >>> incorrect. >>> >>> But more to the point, as I noted in at the bottom of that wiki page, >>> the new assumptions handlers code is very fragile. If you accidentally >>> use the wrong kind of Python logic instead of fuzzy logic, you can >>> return False instead of None. In the best case, you just end up not >>> implementing as much as you thought you were, but in the worst case, >>> you get a wrong result. >>> >>> There are subtle issues that can come up (similar to the >>> https://github.com/sympy/sympy/issues/5976 one) with the new >>> assumptions not being consistant in how it defines assumptions. It >>> doesn't help that it quite often calls out to some external routine to >>> calculate something, which may or may not use the same definition of >>> the assumption that it does. It also uses evalf on most assumptions >>> relating to numbers, which can have its own issues. >>> >>> Aaron Meurer >>> >>> On Sun, Mar 16, 2014 at 5:32 PM, Matthew Rocklin <[email protected]> >>> wrote: >>> > Recall that sets mostly lives in the core. In particular I think that >>> > Interval and maybe Union have been used in the core for some time and >>> > FiniteSet has made itself useful in the last couple years. >>> > >>> > >>> > On Sun, Mar 16, 2014 at 3:31 PM, Matthew Rocklin <[email protected]> >>> > wrote: >>> >> >>> >> > By the way, I didn't know that the sets use exclusively the new >>> >> > assumptions (assuming that is indeed what you are saying here). >>> >> >>> >> That is not what I'm saying. S.Integers and S.Naturals use new >>> >> assumptions. Most of the logic behind core sets doesn't explicitly >>> >> think >>> >> about assumptions at all. So, perhaps worse, sets implicitly uses >>> >> some >>> >> combination of the two. >>> >> >>> >> >>> >> On Sun, Mar 16, 2014 at 2:16 PM, Harsh Gupta <[email protected]> >>> >> wrote: >>> >>> >>> >>> Sorry I accidently pushed Send, ( I was unconsciously entering some >>> >>> vim >>> >>> commands). Ignore the "For" after the example. >>> >>> >>> >>> -- >>> >>> Harsh >>> >>> >>> >>> -- >>> >>> 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 [email protected]. >>> >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at http://groups.google.com/group/sympy. >>> >>> To view this discussion on the web visit >>> >>> >>> >>> https://groups.google.com/d/msgid/sympy/CADN8iupYZiJoBNQxCiAtg0Y-bXF1fNs2PbQtdh9qvYd765L7Sw%40mail.gmail.com. >>> >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> >>> > >>> > -- >>> > 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 [email protected]. >>> > To post to this group, send email to [email protected]. >>> > Visit this group at http://groups.google.com/group/sympy. >>> > To view this discussion on the web visit >>> > >>> > https://groups.google.com/d/msgid/sympy/CAJ8oX-FnZjs4vfBFh%3D2WtMvRdaEM-ndNW%2BqL-rNk5EYQhQ3hVQ%40mail.gmail.com. >>> > >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/sympy. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CAKgW%3D6L5k4Lvep%3DjVvLPbU6JW%3DMrwsrLsV%2Bq3hAFBQr7XDFdoA%40mail.gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Harsh > > > > > -- > Harsh > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CADN8iuocY12bhYgSFkYZCK82jaw1%3D5FGAHFTNoR86ZBuQ9cR9Q%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6K3vSU9Zs%2Be3f-pyfGJ%3D5-%2BpuK-xKO8mZZ6bCSXfuUU7A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
