While going through older postings I came across this reporting a 34S bug:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv020.cgi?read=192437#192437

Sure enough I checked the 41Z to discover I had a similar problem (not exactly the same), which has prompted a new revision.

I also checked free42, rev 1.4.68 - which for me shows the incorrect result as well! Is that what you guys see?

So it appears the example in the 15C manual was a good choice...

The correct result is:

sin-1(2.404) = 1.5708-1.5239i

Hola Ángel,

Before posting that issue, one of the calculators I used for testing was Free42 (one of my refence calculators). and it gave me the same result as the 15c: sin-1(2.404) = 1.5708-1.5239i.

I retested with the newest version (1.4.68), on my phone and on Windows (Decimal and Binary flavours) and I still get the expected answer as it is also now in the WP 34s. Really strange.

Regards,

Miguel

Ángel,

Just tested the Free42, v1.4.68. It gave the correct result.

Aqui tambien: Free42 1.4.66 returns what you stated being the correct result.

komisch: I don;t know what's going on but I keep getting the wrong result (with positive imaginary part). I triple-checked it's the latest version available, even downloaded it twice, and did the test on both my desktop (Win XP) and Laptop (Win7).

So what gives???

Strange. Did you check ASIN(-2.404) as well? What's "your" result there? And for ACOS(2.404) ? Can't imagine anything going wrong there, but your PCs seem to know more ;-)

Quote:

komisch: I don;t know what's going on but I keep getting the wrong result (with positive imaginary part). I triple-checked it's the latest version available, even downloaded it twice, and did the test on both my desktop (Win XP) and Laptop (Win7).
So what gives???

That is odd. I get the correct answer (neg i part) on linux decimal.

Did you try decimal and binary versions? Try a memory reset? Try deleting on the free42 state files in your user dir?

There's in fact an inconsistency in Free42:

asin(2.404)=1.5708-i1.5239

but

asin(2.404+i0)= 1.5708+i1.5239

although both function arguments are of course equal.

Mystery solved ! - and re-opened, let me elaborate:

1.- if you just type 2.404, ASIN -> the result is correct, but...

2.- if you use the complex mode, entering 2.404 ENTER^ 0 COMPLEX ASIN -> the result is wrong!

so what gives? It appears to me that there's some glitch in free42.

Thomas, you around?

Best,

'AM

sorry I din't see your post - exactly!

I've sent an email yesterday to Thomas about this bug, but haven't got an answer yet.

Franz

Hello

I can confirm your findings and it is something that appears between the two version I have :

**Version 1.4.48** : 2.404, x<>y, COMPLEX, SHIFT, ASIN --> **1.5708-i1.5239**

**Version 1.4.68** : 2.404, x<>y, COMPLEX, SHIFT, ASIN --> **1.5708+i1.5239**

Then, something happened in between these two...

Regards,

Miguel

Quote:

**Version 1.4.48** : 2.404, x<>y, COMPLEX, SHIFT, ASIN --> **1.5708-i1.5239**
**Version 1.4.68** : 2.404, x<>y, COMPLEX, SHIFT, ASIN --> **1.5708+i1.5239**

We can let the interval shrink significantly, since:

**Version 1.4.66** : CLST, 2.404, x<>y, COMPLEX, SHIFT, ASIN --> **1.5708-i1.5239**

HTH

*Edited: 13 Sept 2011, 1:54 p.m. *

You may be right. In fact I remember well that fix since it was me who pointed it out to Thomas. I ran into it during my 41Z testing, as I was using Free42 as a reference.

Quote:

It may be a side effect of this fix.

Quote:

13-03-2011: release 1.4.67
* ASIN returned incorrect results for large complex arguments. Fixed.

It seems that way. That fix did correct another ASIN bug, but apparently it introduced this one. I'll have to revisit ASIN and all the other complex inverse trigs and hyperbolics. I'll try to do that this weekend; stay tuned. I'll post a new version on

my web site and iTunes when this is sorted out.

- Thomas

It looks like a branch cut issue. Both the <= 1.4.66 and the >= 1.4.67 code are correct in strictly analytical terms; the former calculates ASIN by multiplying x by i, calculating ASINH, then multiplying by -i, while the latter swaps the real and imaginary parts of x, then calculates ASINH, then swaps the real and imaginary parts back. For a complex analytical function that is also odd, those two approaches are mostly equivalent, *except* for the edge cases. It looks like fixing the behavior near re(z)=infinity broke the behavior near im(z)=0. The results that Free42 returns aren't wrong, but they don't follow the conventions used by the HP-42S (or maybe that means they *are* wrong, and I just didn't realize what the commonly accepted conventions are). If anyone can point me to a reference that lists those conventions, I'd appreciate it! If not, I'll have to spend some time doing some research on how to handle the edge cases correctly.

Note that the code that handles the cases where X is real and |x|>1 are handled by code that's completely separate from the code that handles the case that X is complex (even if the imaginary part is zero). The code for real X where |x|>1 uses arcsin(x)=pi/2-i*arccosh(x) if x>0 and arcsin(x)=-pi/2+i*arccosh(-x) if x<0, and that gives results that match the HP-42S. This code did not change in release 1.4.67. (Hmmm, maybe I should use the same algorithm for the complex case?)

*Edited: 13 Sept 2011, 10:38 p.m. *

I seem to remember the 15c advanced function book mentioned branch cuts...

- Pauli

Thanks for the tip! I'll take a look at that book.

Thomas, here's input from Wolfram Alpha: Link

Regards,

John

Two other reference works that might help are:

[ul]

Abramowitz and Stegun: Handbook of Mathematical Functions which is fantastic reference for many functions.

NIST Digital Library of Mathematical Functions which is a bit more modern and flashier but also very good.
Both of these books are invaluable if you are coding numeric function evaluators. I find paper copies easier to work with than the on line ones (YMMV of course).

I can dig up some other references if necessary. I ended up buying more than a few books on numeric mathematics, function evaluation and floating point arithmetic while doing the 34S numerics. It really is a deep and interesting field.

- Pauli

*Edited: 14 Sept 2011, 12:11 a.m. *

In case it helps, the formulas I use on the 41Z are as follows:

Quote:

asin z = -i * asinh (iz)
asinh z = Ln[z + SQR(z^2 + 1)]

If I recall correctly (working from memory here), the main branch is defined by results with -pi/2 < Im(z) <= pi/2.

I do some adjustments for "large" arguments (their real and imgry parts rather - as defined when (z^2+1 ~ Z^2), remember the NUT CPU has only 10/13 digits in the mantissa. I remember this was what triggered you to "correct" the original implementation.

Edit: the formula can also be expressed as:

asinh z = Ln[z + SQR(z + i) SQR(z - i)]

This has the advantage of not discarding SQRT branches before hand.

Edited: -pi/2 typo, as per below post

*Edited: 14 Sept 2011, 9:37 a.m. after one or more responses were posted*

Quote:

If I recall correctly (working from memory here), the main branch is defined by results with pi/2 < Im(z) <= pi/2.

Well, then there's not much left for Im(z), I'm afraid! ;-)

LOL...

of course should have been:

-pi/2 < Im(z) < pi/2