Quote:

---

The bug in this case is in the code that calculates the complex square root in the log(x+sqrt(x^2+1)) evaluation; it returns the wrong root because the imaginary part of its argument is -0.

In a word: aargh! I'm sure there are good reasons why IEEE-754 has negative zero, but in this case it (or maybe I should say, the way atan2() treats it) is biting me in the ass. It's easy to fix, but I'll have to check all occurrences of atan2() to see if they have the same potential problem. Fortunately, there aren't all that many...

---

can we expect a fix for this new bug, too? ;-)

Franz

Hi,

i'm just going to add another twist here.

a bit late to the party, but i just tried the same acos(cos((200+200i)) on my reckon calculator. unfortunately it fails too. i am using an equally lame formula.

i changed my acos(z) routine to use this:

acos(z) = -2i*log(sqrt((1+z)/2) + i*sqrt((1-z)/2))

it's from Kahan 1987, but i dont have the paper with the theory behind it. anyhow it works fine for this problem. i've changed reckon to use this way of calculating acos and asin.

> acos(cos(200+200i))

1.061929829746767261609178-199.9999999999999999999999i

my 2c.

-- hugh.

looks like my test case is getting a lot of attention :-)

thanks for the formulas, it's an interesting approach.

Best,
'AM.

I'll fix the complex ASIN and ASINH in the Binary version this weekend, and check if any of the other code that uses atan2() in the Binary version is affected by the "negative zero" issue.

The "negative zero" thing only affects the Binary versions, so that doesn't affect my iPhone and Android builds, which are Decimal only. (Is anyone aware of problems with Free42's complex ACOS/ACOSH?)

Edited: 23 Sept 2011, 2:08 a.m.