From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25429 invoked by alias); 17 Oct 2011 08:39:43 -0000 Received: (qmail 25220 invoked by uid 22791); 17 Oct 2011 08:39:40 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 08:39:23 +0000 From: "kreckel at ginac dot de" To: glibc-bugs@sources.redhat.com Subject: [Bug math/13305] New: cacosh(+/-0.5+0.0*i) returns wrong result Date: Mon, 17 Oct 2011 08:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: math X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kreckel at ginac dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: aj at suse dot de X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00124.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13305 Bug #: 13305 Summary: cacosh(+/-0.5+0.0*i) returns wrong result Product: glibc Version: 2.14 Status: NEW Severity: normal Priority: P2 Component: math AssignedTo: aj@suse.de ReportedBy: kreckel@ginac.de Classification: Unclassified Created attachment 6007 --> http://sourceware.org/bugzilla/attachment.cgi?id=6007 patch The current implementation computes cacosh(0.5+0.0*o)=0.0-1.047*i and cacosh(-0.5+0.0*i)=0.0-2.094*i. But that result has the wrong sign. Wes Loewer's patch for BZ#2182 was wrongly applied and should be reverted. The patch tried to fix the choice of branch cut by inverting res, if Re(res)<0.0. This is okay for picking the right branch cut but it suffers to the problem that round-off errors might have occurred in the computation of res. A safer approach is checking the position of the actual argument z. Indeed, the current implementation is doing just that a few lines above, but I don't see this in BZ#2182! Removing the extra test fixes the case. Impact: A different result is computed only when res, as computed so far, has a negative real part. But a negative real part of res can only happen due to round-off errors, as mathematically the argument of log is bounded below by +1.0. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.