Hyperbolic arc cosine fails on (-1) :: Complex r.

When allowing for complex results, the hyperbolic arc cosine is continuously defined on all ℝ.

In the (x < (-1)) real ray of the complex plane, acosh equals \z -> i * pi + acosh(abs z), which works fine for almost all arguments. Thus, acosh (-1) should equal i * pi; however due to the implementation as

acosh z = log (z + (z+1) * sqrt ((z-1)/(z+1)))

where the denominator in the root becomes zero at z = -1, this comes out as NaN :+ NaN.

Could be fixed trivially by adding a special case

acosh ((-1):+0) = 0:+pi

to the instance (RealFloat a) => Floating (Complex a) in Data.Complex.

Trac metadata

Trac field	Value
Version	7.6.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	libraries/base
Test case	acosh(-1) :: Complex Double
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 3

added Tbug Trac import core libraries labels

does this behave as expected in the a small radius around -1? (worth at least plotting it out)

Attached file acosh-on-reals.png (download).

Plot of the complex-valued acosh function, for real arguments.

Replying to [ticket:8532#comment:76992 carter]:

does this behave as expected in the a small radius around -1? (worth at least plotting it out)

For real arguments, it sure enough works.

[[Image(acosh-on-reals.png)]]

GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Complex
Prelude Data.Complex> :m +Graphics.Rendering.Chart.Simple 
Prelude Data.Complex Graphics.Rendering.Chart.Simple> :set prompt "> "
> let re f = realPart . f . realToFrac
> let im f = imagPart . f . realToFrac
> plotPNG "acosh-on-reals.png" [-2, -1.99 .. 2] (re acosh) (im acosh)

If you put in complex numbers, there's a problem anyway: the imaginary part jumps from +π to -π as Im z becomes negative. Still, (http://www.wolframalpha.com/input/?i=acosh) it's apparently convention that for Im z = 0, we always have Im (acosh(z)) ≥ 0), including z = -1. At any rate, the real part is 0 there; but in the current implementation that is also NaN.

hrmm, so one issue with complex functions in general is that there (is always) a "branch cut"

http://mathworld.wolfram.com/BranchCut.html

http://en.wikipedia.org/wiki/Branch_point

http://math.stackexchange.com/questions/245579/how-does-a-branch-cut-define-a-branch

are some of the first few decent hits on google for this topic.

So do we standardize on the "common" branch cut choice? I'm not sure. If we don't enrich the complex function apis to be somehow parameterized by the branchcut choice, thats probably the "right" thing to do. ("right" being of course not quite the right term)

We do pick the standard branch cut location. That said, it is possible to give a more general form with a specified branch cut.

I do so for all of these functions and more for quaternions in http://hackage.haskell.org/package/linear-1.10.1.1/docs/Linear-Quaternion.html

You pick the location of the branch cut by supplying a unit quaternion.

Adapting this logic to a choice of point on the unit circle could be done, but I confess I'd rather hash that out in libraries before asserting it is the right approach for something like base. Almost nobody knows how to use the more exotic cuts, but importantly they can be formed from the standard cut and identities by somone with sufficient background to be aware of the issue.

assigned to @trac-ekmett

Moving over to new owning component 'Core Libraries'.

Trac metadata

Trac field	Value
Component	libraries/base → Core Libraries

assigned to @trac-alekzcb and unassigned @trac-ekmett

Do let me know if you encounter trouble, alekzcb. Thanks for picking this up!

Replying to [ticket:8532#comment:141807 bgamari]:

Do let me know if you encounter trouble, alekzcb. Thanks for picking this up!

I believe I have a simple fix for this, but have been wrangling with arcanist for the past day!

Oh no! What are the symptoms? Feel free to drop by #ghc on irc.freenode.net if you want help.

Cheers bgamari. Just having a bit of trouble submitting my commit. Not sure if it's an Arcanist or a Windows issue. Or an "ID 10T" issue...

For the record, I suspect the issue was that alekzcb didn't have an editor in his PATH. Unfortunately it seems that arcanist doesn't deal with this terribly gracefully.

changed milestone to %8.4.1

Trac metadata

Trac field	Value
Test case	acosh(-1) :: Complex Double → numrun016
Differential revisions	- → D3916

mentioned in commit 6458b8dc

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added incorrect runtime result label

added Plow label