conflicting branch cut conventions

[RBKreckel]

For multi-valued complex functions, the choice of principal values and where complex branch cuts are continuous is a matter of convention but there is a clear predominant convention which has been advocated by Kahan, can be found in Guy Steele's CLTL2 (chapter 12.5.3) and is implemented in most Lisp dialects, in the C99 standard, the upcoming C++0x standard, the CLN library, Mathematica, Maple, Sage's CDF, MPMath, and many others.

However, some libraries disagree with the predominant convention for branch cuts of inverse trigonometric and hyperbolic functions.

Unfortunately for Sage, Pari is one of the systems that disagree. This leads to surprising results that are difficult to explain to new users, like this fine example:

  sage: acosh(-1.0-0.00001*I) - acosh(CDF(-1,-0.0000001))
  -0.00347850806404590 + 6.27970680439127*I

It turns out that all of Pari's branch cuts of inverse trigonometric and hyperbolic functions are somehow affected.

Luckily we don't disagree about roots and the logarithm any more. :-)

• asin: The asin() function is not continuous as the cut is approached coming around the finite endpoint of the cuts in a counter clockwise direction.

• acos: Pari picks an unconventional principal branch in the left complex plain.

• atan: The atan() function is not continous as the cut is appraoched coming around the finite endpoint of the cut along the negative imaginary axis in a counter clockwise direction.

• asinh: The asinh() function is not continuous as the cut is approached coming around the finite endpoint of the cuts in a counter clockwise direction.

• acosh: Pari picks an unconventional principal branch in the lower complex plain.

• atanh: The atan() function is not continous as the cut is appraoched coming around the finite endpoint of the cut along the positive real axis in a counter clockwise direction.

Applying the attached patch to Pari 2.3.5 in Sage 4.5.1 makes the implementations in sage.libs.mpmath, sage.libs.pari, and sage.rings.complex_double return the same values within numerical accuracy.

Upstream: Fixed upstream, but not in a stable release.

CC: @jdemeyer

Component: algebra

Reviewer: Richard B. Kreckel

Issue created by migration from https://trac.sagemath.org/ticket/9620

[RBKreckel]

Attachment: pari-2.3.5.patch.gz

[RBKreckel]

Changed upstream from Not yet reported upstream; Will do shortly. to Reported upstream. Little or no feedback.

[RBKreckel]

comment:1

Reported upstream as http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1084.

[jdemeyer]

comment:3

See #10430

[jdemeyer]

Changed upstream from Reported upstream. Little or no feedback. to Fixed upstream, but not in a stable release.

[jdemeyer]

Reviewer: Richard B. Kreckel

[jdemeyer]

comment:5

Richard B. Kreckel wrote in an email:

So, back to the review:

I've checked that it works fine now. The results of pari(re+imI).f() are compatible with f(CDF(re,im)) and mpmath.f(re+Iim) in the entire complex plain, where f is any of asin, acos, atan, asinh, acosh, and atanh.

thank you -richy.