Ask Your Question

Unexpected behavior of log() in complex plane

asked 2011-10-23 16:46:45 +0200

Xaver gravatar image

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='+')
sage: limit(log(-1+i*eps),eps=0,dir='-')

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 flag offensive 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?

John Palmieri gravatar imageJohn Palmieri ( 2011-10-23 18:01:03 +0200 )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.

Dirk Danckaert gravatar imageDirk Danckaert ( 2011-10-23 18:04:14 +0200 )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.

Xaver gravatar imageXaver ( 2011-10-23 19:10:39 +0200 )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.

jdc gravatar imagejdc ( 2011-10-24 11:35:15 +0200 )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.

kcrisman gravatar imagekcrisman ( 2011-10-24 12:08:51 +0200 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2011-10-24 12:15:24 +0200

kcrisman gravatar image

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.

edit flag offensive delete link more


We could make a bug report at, or make a Sage bug report for amending the documentation of assume, or both, or something else.

kcrisman gravatar imagekcrisman ( 2011-10-24 12:16:34 +0200 )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.

Xaver gravatar imageXaver ( 2011-10-24 16:50:07 +0200 )edit

answered 2011-10-28 23:05:58 +0200

kcrisman gravatar image

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.

edit flag offensive delete link 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*?

Dirk Danckaert gravatar imageDirk Danckaert ( 2011-10-29 17:51:41 +0200 )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.

kcrisman gravatar imagekcrisman ( 2011-10-29 21:22:04 +0200 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-10-23 16:46:45 +0200

Seen: 701 times

Last updated: Oct 28 '11