Subject: "Unexpected behavior of log() in complex plane"
From: Richard Fateman
Date: Fri, 28 Oct 2011 16:07:01 -0700
On 10/28/2011 1:59 PM, Karl-Dieter Crisman wrote:
> On Fri, Oct 28, 2011 at 2:25 PM, Richard Fateman
> <fateman at eecs.berkeley.edu> wrote:
>> The behavior you report below is not the behavior of the Maxima that I just
>> tried it on, 5.23.2.
>>
>> It reports for an answer, log(w).
> Interesting. In that version I get
>
> Maxima 5.23.2 http://maxima.sourceforge.net
> using Lisp ECL 11.1.1
> Distributed under the GNU Public License. See the file COPYING.
> Dedicated to the memory of William Schelter.
> The function bug_report() provides bug reporting information.
> (%i1) declare(w,real);
> (%o1) done
> (%i2) assume(w<0);
> (%o2) [w< 0]
> (%i3) limit(log(w+%i*eps),eps,0);
> (%o3) und
> (%i4) limit(log(w+%i*eps),eps,0,plus);
> (%o4) log(w) + %i %pi
In a fresh version 5.23.2 I get the same answers as you do. In the
process I had running, I got log(w) rather than und.
This is consistent with somehow ignoring the assume(w<0).
>
>> Originally the limit program did not refer directly to assumptions or
>> declarations, and so
>> lines %i1 and %i2 should be irrelevant. Newer versions of limit, or
>> subroutines called during
>> the computation of limits may refer to that information.
> Yeah, that's what I figured.
>
>> Also, originally, the limit program was aimed at computing limits of
>> real-valued functions. If it works in other contexts, that's nice, but not
>> something that was an original intent.
> Ah, that is *definitely* interesting.
>
>> So complex log -- eh, not necessarily supported. But log has multiple
>> values, and to distinguish between
>> log(w)+n*i*pi for odd integer n, and log(-w), is a kind of subtle
>> point, not one that is easily handled by
>>
>> ... just tell me the limit, don't confuse me with, uh, the mathematics...
> Well, the point is that there is supposed to be a well-defined branch
> cut for such functions, and almost universally this is the negative
> real axis (see the post on ask.sagemath.org for Mathematica's
> computation).
I think that anyone who has a serious interest in functions of a single
complex variable and such manipulations as integration is aware that
branch cuts can be moved as a matter of convenience in computations.
I certainly would not refer to whatever Mathematica does as definitive
in this matter.
in the complex context, log(1) is n*pi*I for any integer n.
(complex) log is not a function but a "multivalued function". Any
treatment that tries to pick a single value is essentially doomed in
some circumstances. Sqrt() is similarly going to screw up if you
replace sqrt(x^2) with x, or abs(x). It is both x and -x. Asserting
that x>0 does not change that, in spite of peoples' attempts to take
that as a clue to sqrt()/
> So that the limit would make sense, given this choice
> of branch.
>
> After all, if one does it numerically:
>
> sage: var('eps,w')
> (eps, w)
> sage: f(eps) = log(w+i*eps)
> sage: [f(e).subs(w=-1) for e in [.1,.01,.001,.0001]]
> [0.00497516542658397 + 3.04192400109863*I, 0.0000499975001665547 +
> 3.13159298690313*I, 4.99999750058881e-7 + 3.14059265392313*I,
> 4.99999995711264e-9 + 3.14149265359013*I]
> sage: [f(e).subs(w=-2) for e in [.1,.01,.001,.0001]]
> [0.694395620659239 + 3.09163425786785*I, 0.693159680403698 +
> 3.13659269525583*I, 0.693147305559930 + 3.14109265363146*I,
> 0.693147181809945 + 3.14154265358983*I]
>
> which sure looks like log(-(-2))+I*pi to me. This is the standard cut.
It doesn't matter where you put the cut. log is multivalued.
>
>> So, one answer is: upgrade Sage to a later Maxima.
> No, that doesn't make sense, because the 5.25.0 I tried is later than
> the Maxima in Sage.
Hm, in the future you would save us some time by indicating which Maxima
was used in Sage.
There is a function in Maxima called "plog".
limit(plog(w+%i*eps),eps,0);
gives log(-w)+%i *%pi
note that with the assumption on w, plog(w) alone is
log(-w) +%i*%pi.
The argument of log in this expression is positive since w<0....
RJF