HP Forums

Here's my dilemma:

I looked at Wikipedia here for the logarithmic forms of ACOS.
The second row is the one that interests me.

ACOS(Z)=-i*ln(Z+sqrt(Z^2-1))

Now let's make Z=2 (real, but outside range so result will be complex).

2^2-1 = 3
ln(2+sqrt(3))=1.3169... (all real numbers so far)

Now -i*1.3169... = (0 -1.3169)

Now go to your 50g and do 2 ACOS, you'll get (0 1.3169...) (positive imaginary part)

Wolfram Alpha agrees with the 50g, so that imaginary part has to be positive.

Then a quick check:
ACOS(Z)=pi/2-ASIN(Z)

Doing that on the 50g we also get positive imaginary part.

Is the formula wrong in wikipedia? Perhaps it should be i*ln(...) instead of -i ?

I just need some help proving it, so it's not just me against the world.

EDIT: BTW, the ASIN() formula in Wikipedia works in agreement with the 50g.

(04-28-2016 03:07 PM)Claudio L. Wrote: [ -> ]Here's my dilemma:

I think I figured it out.
I think the formula is right, but the only difference is which branch of the sqrt() you take. For whatever reason, for real numbers the 50g and Wolfram take the negative root, which provides the sign change.
Are there any conventions as far as which branch to take?

If I take an arbitrary number like (2 3), I get the right value, but on reals it goes to the wrong solution (actually I shouldn't say the wrong solution, as both are correct solutions, just goes to "another" solution).

Sorry if I turned this into a monologue, but I'll leave it written for the curious reader.
So how's the 50g and everybody else doing it?

It seems everybody has a slightly different formula for ACOS, but everybody agrees 100% identical for ASIN.
ASIN doesn't have a problem, whether you use the calculator, or do it "by hand" following the formula you get the same result.

Here, all the way to the bottom, we have a formula from Mathworks.
And here is the implementation from Wolfram.

Basically, Wolfram just does pi/2-asin(Z), so the branch chosen is consistent with the ASIN results.
Mathworks uses a formula slightly different from Wikipedia:

Wikipedia uses sqrt(Z^2-1), while the other formula has i*sqrt(1-Z^2).

Before somebody jumps and says "it's the same!", let's try a couple of cases:

Z=2:
sqrt(2^2-1)=1.73...
i*sqrt(1-2^2)=i*sqrt(-3) = i*(i*1.73...) = -1.73...

Z=2+3*i:
sqrt(Z^2-1)=sqrt(-6+12*i)=(1.92...,3.11...)
i*sqrt(1-Z^2)=sqrt(6-12*i)=i*(3.11...,-1.92...)=(1.92..., 3.11...)

Z=2-3*i:
sqrt(Z^2-1)=sqrt(-6-12*i)=(1.92...,-3.11...)
i*sqrt(1-Z^2)=sqrt(6+12*i)=i*(3.11...,1.92...)=(-1.92..., 3.11...)

Very subtle... the second form gives results consistent with the 50g for all values.
It would never occur to me that such a trivial expression manipulation would push you through a different solution. Very sneaky.

It's commonly accepted to define as "principal" branch the solution with argument between -pi and pi. This is covered with good explanations in the 15C Special Functions Manual, I'm sure somebody here will be able to point at its URL...

(04-28-2016 05:03 PM)Claudio L. Wrote: [ -> ]Before somebody jumps and says "it's the same!", let's try a couple of cases:
(...)
Very subtle...

I wouldn't call this subtle, but obvious. At least as long as you do not forget that a square root has both a positive and a negative value:


So it's actually OK to jump in and say "it's the same!". ;-)

Dieter

(04-28-2016 06:44 PM)Dieter Wrote: [ -> ]I wouldn't call this subtle, but obvious.

Well... wasn't so obvious to me, of course I'm well familiar with multivalued functions, but usually conventions dictate which value is the principal, and that's the end of it, calculations are straightforward and as long as you keep in the back of your mind that there's other solutions you can proceed without changes.
What got me is that using sqrt(z) vs. i*sqrt(-z) changes the selected branch only for some values, but not all.

(04-28-2016 06:44 PM)Dieter Wrote: [ -> ]So it's actually OK to jump in and say "it's the same!". ;-)

Dieter

I knew somebody was going to... enjoy your moment of glory :-)

Now if I leave newRPL returning the other solution for ACOS... would you be the first one telling me "it's not the same! the other solution is the right one!" ?
I guess we'll never know... I made sure newRPL returns the expected value :-)

(04-28-2016 06:42 PM)Ángel Martin Wrote: [ -> ]It's commonly accepted to define as "principal" branch the solution with argument between -pi and pi. This is covered with good explanations in the 15C Special Functions Manual, I'm sure somebody here will be able to point at its URL...

I know it might seem trivial, but once you get into the subject in depth it's a mess.
Each transcendental function has its own weird branch cuts, not so trivial as you can see here.
EDIT: What you mentioned works for ln() and sqrt(), acos() is a different animal.

.
Hi, Ángel:

(04-28-2016 06:42 PM)Ángel Martin Wrote: [ -> ]It's commonly accepted to define as "principal" branch the solution with argument between -pi and pi. This is covered with good explanations in the 15C Special Functions Manual, I'm sure somebody here will be able to point at its URL...

Here you are:

HP-15C Advanced Functions Handbook

Best regards.
V.
.

(04-28-2016 08:58 PM)Valentin Albillo Wrote: [ -> ].
Hi, Ángel:

(04-28-2016 06:42 PM)Ángel Martin Wrote: [ -> ]It's commonly accepted to define as "principal" branch the solution with argument between -pi and pi. This is covered with good explanations in the 15C Special Functions Manual, I'm sure somebody here will be able to point at its URL...

Here you are:

HP-15C Advanced Functions Handbook

Best regards.
V.
.

Thanks for the link! Page 61 lists for ACOS the same formula as Wikipedia. Does this mean ACOS on the 15C returns the other values?
Can somebody run ACOS(2) on the 15C?

(04-29-2016 02:19 AM)Claudio L. Wrote: [ -> ]Thanks for the link! Page 61 lists for ACOS the same formula as Wikipedia. Does this mean ACOS on the 15C returns the other values?
Can somebody run ACOS(2) on the 15C?

HP-15C S/N:2435A04214

(04-29-2016 02:50 AM)Sylvain Cote Wrote: [ -> ]

(04-29-2016 02:19 AM)Claudio L. Wrote: [ -> ]Thanks for the link! Page 61 lists for ACOS the same formula as Wikipedia. Does this mean ACOS on the 15C returns the other values?
Can somebody run ACOS(2) on the 15C?

HP-15C S/N:2435A04214

Code:

FIX 9
SF 8
2
ACOS     [X: 0]
Re<>Im   [X: 1.316957897]

41Z Module, any revision:

Z, 2 = 2 + j0
ZACOS = 0 + 1.316957897E0

When I programmed the 41Z I had to delve into this one at length. I even found a bug in Free42 (that I was using to check the results) which Thomas duly corrected very promptly, interestingly in the inverse trigonometric functions. I don't remember how I came up with the right value selection, but it must have been by applying the branch definition criteria all across the chain of intermediate calculations; how else.

(04-28-2016 08:29 PM)Claudio L. Wrote: [ -> ]

(04-28-2016 06:42 PM)Ángel Martin Wrote: [ -> ]It's commonly accepted to define as "principal" branch the solution with argument between -pi and pi. This is covered with good explanations in the 15C Special Functions Manual, I'm sure somebody here will be able to point at its URL...

I know it might seem trivial, but once you get into the subject in depth it's a mess.
Each transcendental function has its own weird branch cuts, not so trivial as you can see here.
EDIT: What you mentioned works for ln() and sqrt(), acos() is a different animal.

That's not logical; once a branch of the logarithm is used it should apply to all your functions and provide the same criteria across. The Ln is the root cause of every multi-value here, including the square root which is nothing more that another logarithm if you use the expression SQRT(z) = exp [ ln(z) / 2]. The ACOS function is more of the same, in this instance with the rule applied twice since the ln appears twice in its expression - or even three times if you'd use Z^2 = exp [ 2 ln(z) ] ...

The branch selection is therefore critical. I remember in complex analysis classes we sometimes needed to change the branch to avoid function singularities during integration, as in the integration path crossing the cut where the function wasn't analytical. It's been a while since that so I may also remember wrong though I suspect the basic concepts are still clear in my memory.

(04-28-2016 05:03 PM)Claudio L. Wrote: [ -> ]the other formula has i*sqrt(1-Z^2).

I asked my Maple:
convert(arccos(x),ln);
-I*ln(x+I*sqrt(1-x^2))


Maybe it help
Csaba

(04-29-2016 06:06 AM)Ángel Martin Wrote: [ -> ]That's not logical; once a branch of the logarithm is used it should apply to all your functions and provide the same criteria across. The Ln is the root cause of every multi-value here, including the square root which is nothing more that another logarithm if you use the expression SQRT(z) = exp [ ln(z) / 2]. The ACOS function is more of the same, in this instance with the rule applied twice since the ln appears twice in its expression - or even three times if you'd use Z^2 = exp [ 2 ln(z) ] ...

The branch selection is therefore critical. I remember in complex analysis classes we sometimes needed to change the branch to avoid function singularities during integration, as in the integration path crossing the cut where the function wasn't analytical. It's been a while since that so I may also remember wrong though I suspect the basic concepts are still clear in my memory.

You are right, once you select the right convention for which branch to take on sqrt() and ln(), acos() should be automatic... or that's what I thought, that's the whole point of this thread.
The formula is supposed to take the branch cut of the sqrt(), then shift it, then ln() remaps it and adds its own branch cuts.
The whole point is that, like you, I expected this to be taken care of automatically, but that's not the case with the formula from Wikipedia or the 15C manual. It does work great when you use i*sqrt(1-Z^2), rather than sqrt(z^2-1).
It seems the 15C and the 41 (thank to all who provided the results) agree with the branch cuts of i*sqrt(1-Z^2), so why is the formula in the manual showing sqrt(Z^2-1)? same question to the Wikipedia folks and a couple of other websites I found.

There's very good agreement in the results between all calculators and major CAS systems (thanks to the Maple check in this thread), it's the docs that cause the discrepancy.

If I'm interpreting correctly the ACOS illustration from HP 15C Advanced Functions Handbook, page 61, then the positive real axis for x>1 (blue line) is mapped to the positive imaginary axis - means documentation and implementation are consistent. Note that the principal value is denoted with all cap letters (on top of right-hand illustration), where lowercase letters are denoting the multi-value inverse, see explanation on the page 59.

(04-29-2016 09:15 PM)ljubo Wrote: [ -> ]If I'm interpreting correctly the ACOS illustration from HP 15C Advanced Functions Handbook, page 61, then the positive real axis for x>1 (blue line) is mapped to the positive imaginary axis - means documentation and implementation are consistent. Note that the principal value is denoted with all cap letters (on top of right-hand illustration), where lowercase letters are denoting the multi-value inverse, see explanation on the page 59.

Interesting, I never looked at those diagrams as showing mappings between domain and results regions but as defining the ranges of applicability, i.e. showing where will the results be; yet what you're saying appears to be accurate.

What's intriguing is the sentence in pg. 62: "The principal branches in the last four graphs above are obtained from the equations shown, but don't necessarily use the principal branches of ln(z) and sqr(z)"

So this leads us to believe that in some cases they had another criteria for choosing the principal branches, like keeping symmetries or other properties to make them more analogous to the behavior in the real domain.

Oh and I remember better now: for contour integrals involving multi-valued (or other) functions the method wasn't to change the branch but to make the integration path "elude" the singularities - thus those funny "C" shapes and circles around the poles.


Perhaps a mathematician in the audience could stop our poking the beast and provide a more rigorous clarification?

(04-30-2016 07:01 AM)Ángel Martin Wrote: [ -> ]Interesting, I never looked at those diagrams as showing mappings between domain and results regions but as defining the ranges of applicability, i.e. showing where will the results be; yet what you're saying appears to be accurate.

Well, there is no other definition of single-valued inverse function (restricted to the principal branch). Without diagram they would need some curly brackets and different equations depending of Re(z) and Im(z) >1, <-1, etc.

(04-30-2016 07:01 AM)Ángel Martin Wrote: [ -> ]What's intriguing is the sentence in pg. 62: "The principal branches in the last four graphs above are obtained from the equations shown, but don't necessarily use the principal branches of ln(z) and sqr(z)"

They have introduced a clear notation and are sticking to it: "In the discussion that follows, the single-valued inverse function (restricted to the principal branch) is denoted by uppercase letters-such as COS−1(z)—to distinguish it from the multivalued inverse—cos−1(z)." (page 59).
When reading one needs to differentiate between functions in uppercase and in lowercase in equations.

(04-30-2016 07:01 AM)Ángel Martin Wrote: [ -> ]So this leads us to believe that in some cases they had another criteria for choosing the principal branches, like keeping symmetries or other properties to make them more analogous to the behavior in the real domain.

Definitely, on the page 60 they are writing: "The principal branches used by the HP-15C were carefully chosen. First, they are analytic in the regions where the arguments of the real-valued inverse functions are defined. That is, the branch cut occurs where its corresponding real-valued inverse function is undefined. Second, most of the important symmetries are preserved. For example, SIN−1(−z) = -SIN−1(z) for all z."

Interesting question is why are they choosing Im(ARCCOS(z))>0 for Re(z)>1 and Im(z)=0, maybe it is related to ARCCOS(-x) = pi - ARCCOS(x), but I don't see it yet. It needs to be consistent with arccos(x) = pi/2 - arcsin(x) - so in a way it is consequence of arcsin principal branch.

(04-30-2016 07:01 AM)Ángel Martin Wrote: [ -> ]Perhaps a mathematician in the audience could stop our poking the beast and provide a more rigorous clarification?

I'm a physicist - so almost a mathematician :-), but yes, it is interesting question why they have chosen this exact principal branch - or in other words, what would be broken or "ugly" if principal branch would be different, especially if they would took Im(ARCCOS(z))<0 for Re(z)>1 and Im(z)=0.

(04-30-2016 08:57 AM)ljubo Wrote: [ -> ]...it is interesting question why they have chosen this exact principal branch - or in other words, what would be broken or "ugly" if principal branch would be different, especially if they would took Im(ARCCOS(z))<0 for Re(z)>1 and Im(z)=0.

Thank you, now I don't feel so dumb. The first few posts seemed to dismiss this as something trivial that I should've known since third grade. I'm glad to see now that it wasn't so trivial.
Back on topic, it seems you are on the right track, I think those branches were chosen to preserve the symmetries and the relationships between asin() and acos() that we know from the real realm.
I guess all you have to do is get a list of all symmetries, and test them using the Wikipedia formula for acos().
I can easily see acos(Z)=pi/2-asin(Z) failing if you have the other branch, since the sign of the imaginary part is opposite, you'd get acos(Z)=pi/2-conj(asin(Z)).