Bug 10716 - various problems in cacosh and cacos
Summary: various problems in cacosh and cacos
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: math (show other bugs)
Version: 2.10
: P2 normal
Target Milestone: ---
Assignee: Joseph Myers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-01 09:52 UTC by Paul Zimmermann
Modified: 2014-07-01 06:44 UTC (History)
2 users (show)

See Also:
Host: x86_64-redhat-linux
Target: x86_64-redhat-linux
Build: x86_64-redhat-linux
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Zimmermann 2009-10-01 09:52:23 UTC
The classical branch cut for cacosh() is (-inf, 1). However, cacosh() is using
a different branch cut. For example (courtesy of Kaveh Ghazi):

cacosh(-1 + -0 I) -> (0 + 3.14159265358979 I)

With the classical branch cut, one would get (0 - 3.14159265358979 I).

Also the sign of 0 is not always correct:

cacos(1 + 0 I) -> (0 + 0 I) [should be (0 - O I)]

Finally the documentation of cacosh says that the real part of the result is
chosen non-negative, which is clearly wrong on this example:

cacosh(-3.45677995681763 + -2.3456699848175 I) -> (-2.11780021549476 +
2.53187508681341 I)

See
<http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-October/000581.html>
for more details.
Comment 1 Richard B. Kreckel 2011-11-23 08:45:16 UTC
(In reply to comment #0)
> The classical branch cut for cacosh() is (-inf, 1). However, cacosh() is using
> a different branch cut.

Branch cuts being standardized in C99 this is now a matter of conformance!

> cacosh(-1 + -0 I) -> (0 + 3.14159265358979 I)

After applying the patch attached to BZ #13305 the correct result 0 - 3.14159265358979*I is returned.

> cacos(1 + 0 I) -> (0 + 0 I) [should be (0 - O I)]

This is how cacos is computed by glibc:
cacos(x)
  ->  Pi/2 - casin(x)
  ->  Pi/2 - casinh(x I)/I
So, cacos(1 + 0 I) eventually ends up computing casinh(-O + I) which, in turn, is computed using log(x+sqrt(1+x^2)). But that formula stands no chance getting the sign of zero in the real part right along the strip running from -I to +I. To fix it, it would have to be rewritten using a formula that computes the real and the imaginary part completely independently.

> Finally the documentation of cacosh says that the real part of the result is
> chosen non-negative, which is clearly wrong on this example:
> 
> cacosh(-3.45677995681763 + -2.3456699848175 I) -> (-2.11780021549476 + 2.53187508681341 I)

This appears to have been fixed long ago with BZ #2153.
Comment 2 Joseph Myers 2012-03-06 02:58:52 UTC
Confirmed (as regards signs of 0) with current sources.  Patch: http://sourceware.org/ml/libc-alpha/2012-03/msg00112.html
Comment 3 Joseph Myers 2012-03-07 15:16:46 UTC
Fixed by:

commit d1d3431a3a9dd14501eedb701436bd5005b1db7d
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Mar 7 15:15:19 2012 +0000

    Fix signs of zeros from casinh, cacosh etc. (bug 10716).