# Unexpected behavior of log() in complex plane

For the log() to be defined properly in the complex plane we need to agree on where its cut is located. So, for sage it is easy to check that the cut is located on the negative Re-axis (as is most common), namely

sage: var('eps')
sage: limit(log(-1+i*eps),eps=0,dir='+')
I*pi
sage: limit(log(-1+i*eps),eps=0,dir='-')
-I*pi


Ok. Now I want to use this with symbolic variables. So I do

sage: var('w eps')
sage: forget()
sage: assume(w,'real')
sage: assume(w>0)
sage: limit(log(-w+i*eps),eps=0,dir='+')
I*pi + log(w)
sage: limit(log(-w+i*eps),eps=0,dir='-')
-I*pi + log(w)


Ok. That is correct. Now I want to get a little more adventurous, namely

sage: var('w ec eps')
sage: forget()
sage: assume(w,'real')
sage: assume(ec,'real')
sage: assume(eps,'real')
sage: assume(w>0)
sage: assume(w<ec)
sage: limit(log(w-ec+i*eps),eps=0,dir='+')
I*pi + log(-ec + w)
sage: limit(log(w-ec+i*eps),eps=0,dir='-')
-I*pi + log(-ec + w)


Oops? This is wrong. The argument of the log() has not been turned into the absolute value its real part, i.e. ec-w. This also contradicts the previous simpler startup examples.

Just for backup. Mathematica will give you

In[6]:= Limit[Log[w-ec+I eps],eps->0,Direction->-1,Assumptions->{w>0,w<ec}]
Out[6]= I Pi+Log[ec-w]
In[7]:= Limit[Log[w-ec+I eps],eps->0,Direction->1,Assumptions->{w>0,w<ec}]
Out[7]= -I Pi+Log[ec-w]


As I was expecting and at variance with sage's output.

edit retag close merge delete

The documentation for log says that it picks "the branch with angle between -pi and pi." So you're saying that this is not the actual behavior?

( 2011-10-23 18:01:03 +0100 )edit

I have an even simpler example that shows that your startup example 2 was only correct by chance: var('w,eps') forget() assume(w,'real') assume(w<0) limit(log(w+i*eps),eps=0,dir='+') This is evaluated as I*pi + log(w) I don't know what exactly goes on here, but it seems the whole 'assume()'-business in SAGE is behaving unintuitively, if not just wrong.

( 2011-10-23 18:04:14 +0100 )edit

@John Palmieri: with z=r * e^(i * phi), where r=|z|, we have log(z)=i*phi+log(|z|). As always we have to chose how to count phi. The 1st and 2nd example agree with sage having the branch cut on the negative real axis with phi=+pi in the upper half and -pi in the lower half plane. The 3rd example still agrees with that but the real part is not log(|z|), which would be log(ec-w), but log(w-ec), which is not even defined, since w-ec is real and negative. The last example shows that Mathematica does this right. It has Log[ec-w], which is ok.

( 2011-10-23 19:10:39 +0100 )edit

Good catch, Xaver -- this does seem like a bug. No matter what branch you use to evaluate log(-ev+w) in that output, Sage's answer is wrong.

( 2011-10-24 11:35:15 +0100 )edit

We should be able to do these examples in pure Maxima, since the limit and assumption facilities are from Maxima. HOWEVER, Maxima is pretty explicit that its integrals and solve commands do *not* take account of assumptions like that very much, because 1) their assumption facilities are "weak" (obviously stronger than anything else in Sage, though) and 2) often they let things in things like solve be treated as dummy variables, differently from how it works in Python/Sage where you can't really do that.

( 2011-10-24 12:08:51 +0100 )edit

Sort by » oldest newest most voted

This is not an answer, but I need markup - this is @Dirk Danckaert's example in pure Maxima.

(%i1) declare(w,real);
(%o1)                                done
(%i2) assume(w<0);
(%o2)                               [w < 0]
(%i3) limit(log(w+%i*eps),eps,0);
(%o3)                                 und


(that is, undefined)

(%i4) limit(log(w+%i*eps),eps,0,plus);
(%o4)                           log(w) + %i %pi


so the problem is in Maxima, if they would consider it a problem.

more

We could make a bug report at https://sourceforge.net/tracker/?func=add&group_id=4933&atid=104933, or make a Sage bug report for amending the documentation of assume, or both, or something else.

( 2011-10-24 12:16:34 +0100 )edit

@kcrisman, where ever it comes from, let it be Sage or Maxima, my feeling is that just amending the documentation of 'assume' is not a real solution of this (complex ;) ) problem. It is the log() ... it is most basic math ... and it is not working correctly. This should be fixed. Is this just a bug in the log(), or in how 'limit' works, or in 'assume', or maybe even in other elementary functions? I consider this 'bug' as @jdc puts it, as rather frightening. I was on the verge of using Sage to analyze the analytic properties of some far more involved functions in the complex plane then just the log(). Now I fear one should better stay away from that. Please keep me posted on this issue.

( 2011-10-24 16:50:07 +0100 )edit

Here is a way to get Maxima to do this within Sage. See the Maxima list thread about this issue. Fateman is one of the preeminent authorities on computer algebra.

sage: var('w,eps')
(w, eps)
sage: assume(w,'real')
sage: assume(w<0)
sage: E = (w+i*eps).maxima_methods().plog()


This is a relatively new thing which allows much easier access to most Maxima methods. Here, we are accessing a principal value version of the log.

sage: limit(E,eps=0,dir='+')
I*pi + log(-w)


I hope this clarifies things.

Essentially, the issue is that Maxima (and hence symbolic Sage) wants its log, sqrt, and other multi-valued functions to stay multivalued as long as possible, really forever. So anything like what you want is not really correct to ask for, according to that point of view (because log(w) and log(-w) are both the same set of values).

So, as far as we can tell, the assumption is just ignored in the original limit, which was my original suspicion.

I realize you want something different from it, but it's not so much about being wrong as having different goals.

more

Am I correct when I say this implies that Maxima - and hence symbolic Sage - in fact doesn't support *real* analysis, but only *complex analysis*?

( 2011-10-29 17:51:41 +0100 )edit

Well, that probably depends on what you want. It *is* true that Maxima generally tries for the most multi-valued answer with such things (so that sqrt(x^2)\neq abs(x), but rather either x or -x). On the other hand, presumably there are plenty of things you can still do; in the same Maxima list thread, they point out that the limit function originated as intentionally *only* real, with any complex behavior being of more recent vintage. I have to admit that when I approach analysis, it's very much non-computational! Epsilons and deltas, please.

( 2011-10-29 21:22:04 +0100 )edit