On Tue, Jul 5, 2011 at 5:16 AM, Tom Bachmann <[email protected]> wrote: >>> However, this does not work for all functions. Generically, this will >>> fail >>> when we replace sin(sqrt(z)) above by a non-elementary function (i.e. one >>> that is not recognised by the simplification machinery) branched at the >>> origin. A particular example I have hit is uppergamma(0, z). As you may >>> know, the function uppergamma(s, z) (for fixed s) is an entire function >>> when >>> s is a positive integer, satisfies uppergamma(s, z) = z**s * F(s, z) for >>> an >>> entire function F if s is not an integer, and satisfies uppergamma(s, >>> exp(2*pi*I*n)*z) = uppergamma(s, z) + 2*pi*n/factorial(-s) for >>> non-positive >>> integral s. >> >> Which simplification machinery are you referring to? >> > > That's a fair question. It's funny how I sometimes can't tell where a > particular simplification comes from. In this case there is nothing specific > to do at all: > >>>> p = Symbol('p', real=True) >>>> sqrt(exp(I*pi)) > exp(I*pi/2)
Did you maybe mean something different (you're not using p). But anyway, I see that you're referring to the automatic evaluation. By the way, I know of at least on example in Maple where a composite function is defined as a single function because of branch differences, lnGAMMA (http://www.maplesoft.com/support/help/Maple/view.aspx?path=GAMMA&term=lngamma). From that page: "For complex z, Maple evaluates the principal branch of the log-Gamma function, which is defined by analytic continuation from the positive real axis. Each of the points z=0,-1,-2,..., is a singularity and a branch point, and the union of the branch cuts is the negative real axis. On the branch cuts, the values of lnGAMMA(z) are determined by continuity from above. (Note, therefore, that lnGAMMA <> ln@GAMMA in general.)" mpmath does this with some functions, though I think it's usually for efficiency rather than because of branch differences. Anyway, if you can solve this in a more general way, that would be preferred. Aaron Meurer > >>> >>> My question thus is how to put this information into code. Notice that >>> all >>> functions in question come from meijer g-functions, but I don't think >>> there >>> is a chance of understanding the monodromy action in this generality (but >>> I >>> would love to be wrong!). Assuming this is true, the best I could come up >>> with would be to add ._eval_rewrite_as_{un,}branched functions to special >>> functions, perhaps even with a default implementation raising >>> NotImplementedError. This would be somewhat akin to the >>> ._eval_rewrite_as{in,}tractable used for gruntz' algorithm. >>> >>> [Since the answer is likely messy, any code should obviously try to avoid >>> calling these functions at any cost, but that is something I can take >>> care >>> of locally.] >>> >>> In more detail, somewhere in functions/elementary/complexes.py I would >>> add >>> principal_branch(z) which represents z with its argument converted to >>> range >>> (-pi, pi], and argument_period(z) which then satisfies z = >>> principal_branch(z)*exp(I*2*pi*argument_period(z)). Then e.g. >>> uppergamma._rewrite_as_unbranched could return an expression involving >>> these >>> functions. The integration code would use a sequence of operations as >>> follows to compute the branch of the result: >>> >>> # TODO try to avoid this when possible >>> res = res.rewrite('unbranched') >>> res = res.subs(my_pi, pi) >>> res = res.rewrite('branched') >>> >>> My real questions are then as follows, I guess: >>> >>> 1. Does anyone see a better way around the issue? >>> 2. Any suggestions for a better interface? >>> >>> Thanks, >>> Tom >>> >> >> I don't see any problems with it, but complex analysis is not my >> strength, as I haven't take the course yet (I will have it next >> semester), so I only know what I've picked up. I think the rewrite >> machinery should be rewritten to be more powerful, but this is likely >> beyond the scope of your project. >> > > I will do this, then. > >> Aaron Meurer >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" 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?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" 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?hl=en.
