From tshort at eprisolutions.com  Mon Dec  4 04:12:19 2006
From: tshort at eprisolutions.com (tshort)
Date: Sun, 3 Dec 2006 19:12:19 -0800 (PST)
Subject: [Rd] bug in acosh (win32) (PR#9403)
In-Reply-To: <20061203142723.DF37B572B3@slim.kubism.ku.dk>
References: <20061130140947.48027103EA@slim.kubism.ku.dk>
	<20061203142723.DF37B572B3@slim.kubism.ku.dk>
Message-ID: <7670239.post@talk.nabble.com>


> This is a bug in the mingw runtime, and not in R.  So the difference is 
> between OSes, not between R versions.  Note that
> 
> > acosh(2)
> [1] 1.316958
> > acosh(2+0i)
> [1] 0+NaNi
> > acosh(2+1e-10i)
> [1] 1.316958+0i
> 
> so it seems to be happening only for exactly real complex numbers.
> I think there are also problems with branch cuts.
> 

Interesting. Unfortunately, that's a common scenerio to convert to
complex numbers to ensure complex output if appropriate:
acosh(as.complex(-2))

I guess acosh(as.complex(x) + 1e-10i) is a bit better than my current
workaround of:

myacosh <- function(x) log(x + sqrt(x^2 - 1))

> 
> On Thu, 30 Nov 2006, tshort at eprisolutions.com wrote:
> 
> > Full_Name: Tom Short
> > Version: 2.4.0
> > OS: Windows XP
> > Submission from: (NULL) (68.236.159.227)
> >
> >
> > It looks like there's a bug in acosh with complex number in windows:
> >
> >> acosh(2)
> > [1] 1.316958
> >> acosh(2+0i)
> > [1] 0+NaNi
> >
> > This happens for me on Windows XP with the following versions:
> > R version 2.2.0, 2005-10-06, i386-pc-mingw32
> > R version 2.4.0 (2006-10-03) i386-pc-mingw32
> >
> > It works fine with the following:
> > R version 2.4.0 (2006-10-03) i386-pc-linux-gnu (debian)
> > R version 2.1.0, 2005-04-18, i386-pc-linux-gnu (debian)
> >
> >> acosh(2+0i)
> > [1] 1.316958+0i
> >
> > I didn't find any problem with asinh or atanh taking complex numbers. In
> > src/main/complex.c, there are some #ifdef Win32's in z_asin and z_acos,
> so it
> > may be related to that.
> 
> acosh is unrelated to those.

According to this:
http://mingw.cvs.sourceforge.net/mingw/runtime/mingwex/complex/cacosh.c?view=markup
cacosh uses either casin or cacos, so it looks like they are
related. And, the ifdef's for z_acos and z_asin both say "broken for
cabs(*z) >= 1", matching this:

> acosh(.99+0i)
[1] 0+0.1415395i
> acosh(1.01+0i)
[1] 0+NaNi

That also turned up a similar bug in mingw's asinh, this time with
real and imaginary components swapped:

> asinh(2i)
[1] 0+NaNi
> asinh(1e-10 + 2i)
[1] 1.316958+1.570796i

- Tom
Tom Short
EPRI Solutions, Inc.

> > - Tom
> >
> > Tom Short
> > EPRI Solutions, Inc.
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
View this message in context: http://www.nabble.com/bug-in-acosh-%28win32%29-%28PR-9403%29-tf2731987.html#a7670239
Sent from the R devel mailing list archive at Nabble.com.



[Rd] bug in acosh (win32) (PR#9403)
tshort