▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
While going through older postings I came across this reporting a 34S bug:
http://www.hpmuseum.org/cgisys/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:
sin1(2.404) = 1.57081.5239i
▼
Posts: 239
Threads: 55
Joined: Sep 2006
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: sin1(2.404) = 1.57081.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
Posts: 69
Threads: 5
Joined: May 2009
Ángel,
Just tested the Free42, v1.4.68. It gave the correct result.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Aqui tambien: Free42 1.4.66 returns what you stated being the correct result.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
komisch: I don;t know what's going on but I keep getting the wrong result (with positive imaginary part). I triplechecked 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???
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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 ;)
Posts: 102
Threads: 3
Joined: Sep 2007
Quote:
komisch: I don;t know what's going on but I keep getting the wrong result (with positive imaginary part). I triplechecked 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?
Posts: 1,216
Threads: 75
Joined: Jun 2011
There's in fact an inconsistency in Free42:
asin(2.404)=1.5708i1.5239
but
asin(2.404+i0)= 1.5708+i1.5239
although both function arguments are of course equal.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
sorry I din't see your post  exactly!
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
I've sent an email yesterday to Thomas about this bug, but haven't got an answer yet.
Franz
Posts: 1,253
Threads: 117
Joined: Nov 2005
Mystery solved !  and reopened, 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
▼
Posts: 239
Threads: 55
Joined: Sep 2006
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.5708i1.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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
Version 1.4.48 : 2.404, x<>y, COMPLEX, SHIFT, ASIN > 1.5708i1.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.5708i1.5239
HTH
Edited: 13 Sept 2011, 1:54 p.m.
▼
Posts: 169
Threads: 12
Joined: Aug 2007
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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.
Posts: 727
Threads: 43
Joined: Jul 2005
Quote: It may be a side effect of this fix.
Quote: 13032011: 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
▼
Posts: 727
Threads: 43
Joined: Jul 2005
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 HP42S (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/2i*arccosh(x) if x>0 and arcsin(x)=pi/2+i*arccosh(x) if x<0, and that gives results that match the HP42S. 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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I seem to remember the 15c advanced function book mentioned branch cuts...
 Pauli
▼
Posts: 727
Threads: 43
Joined: Jul 2005
Thanks for the tip! I'll take a look at that book.
▼
Posts: 256
Threads: 4
Joined: Sep 2007
Thomas, here's input from Wolfram Alpha: Link
Regards,
John
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
Posts: 1,253
Threads: 117
Joined: Nov 2005
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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! ;)
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
LOL...
of course should have been:
pi/2 < Im(z) < pi/2
