HP Forums

Full Version: (a + ib)^(x + iy) on HP 15C
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I have been looking at the complex mode on my Hp 15C and thought I would develop a program to calculate

Z = (a + ib)^(x + iy).

I transformed the equation into the form

Z = r^x * exp(-y * theta + i(x * theta + y * ln(r)))

where

r = sqrt(a^2 + b^2)
theta = arctan(b / a)

I did not have much success using the complex operations so I broke the equation down to its real and imaginary parts
giving

Zreal = r^x * exp(-y * theta) * cos(alpha)
Zimag = r^x * exp(-y * theta) * sin(alpha)

where

alpha = x * theta + y * ln(r)

My implementation on the HP 15c is ver y rudimentary and does not use the complex mode at all.

g P/R
f clr Prgrm
f clr Reg
g RAD
f Lbl A
R/S
STO 0 - a
R/S
STO 1 - b
R/S
STO 2 - x
R/S
STO 3 - y
RCL 0
gX2
RCL 1
gX2
+
sqrt
STO 4 - r
RCL 1
RCL 0
/
arcTAN
STO 5 - theta
RCL 3
x
CHS
exp^X
RCL 4
RCL 2
y^X
x
STO 6 - r^x exp(-y*theta)
RCL 2
RCL 5
x
RCL 4
g LN
RCL 3
x
+
STO 7
COS
RCL 6
x
R/S - Zreal
RCL 7
SIN
RCL 6
x
R/S - Zimag

The test results match with those I generatred in Mathcad.

a b x y Zreal Zimag
1 2 5 3 -0.19327557 2.00888766
15 2 5 3 -436596.2108 306080.3182
20 2 5 3 -2425781.2385 -183953.00483

Any suggestions?

Chris

Hi Chris,

your program is performing well. I checked it with the build-in complex x^y function on my HP 15C, see p. 131 of the Owner's Handbook.


Edited: 29 July 2008, 3:48 p.m.

George

How did I miss it! Thanks. I bet your program is very compact. It looks as though I may have made a mountain out of a mole hill. Still I enjoyed the chase!

Thanks

Chris

Edited code update

This is more intuitive


f LBL B
R/S
ENTER
R/S
f I
R/S
ENTER
R/S
f I
y^X
R/S
f Re >< Im
R/S

and shorter!!

Again thanks for the tip

Chris

Edited: 29 July 2008, 4:31 p.m.

Quote:
I bet your program is very compact.

As you now know I don't need a program to do x^y on complex numbers. For those who don't have the manual, the required keystrokes would be:

"1"
ENTER
"2"
f I
"5"
ENTER
"3"
f I
x^y

The result's real part is in X now. To check the imaginary part, press f (i) and hold (i).

Hi, Chris --

Writing applications for the HP-15C can be surprisingly rewarding, due to its verstile and extensive capabilities (albeit at slow computational speed).

One stellar attribute of the HP-15C is the full domain and range of its complex-number functionality. This was pioneering in handheld calculators in 1982, and still is rarely achieved in most of today's models. As George stated, you can simply use its built-in capability to calculate the complex-valued result of raising one complex-valued number to another complex-valued number. Of course, you notice that the HP-15C display goes blank for a while during these extensive computations; even the Pioneer-series HP-32S/32SII and HP-42S (which are 12 times as fast) do not give results instantly for this calculation.

If your goal was to perform such a computation outside of complex mode, you should put rectangular<->polar conversions to good use:


(a + jb)(x + jy)

= eln[(a + jb)(x + jy)]

= e[(x + jy)*ln(a + jb)]

ln(a + jb) = ln |a + jb| + j*atan2(a, b) [radians]

and

e(c + jd) = ec*ejd

So, you can use ->P to calculate the logarithm using two reals. Then, after computing the complex-valued product, use ->R with magnitude of 1.00 to find the exponential of the imaginary-valued part, and multiply by the exponential of the real-valued part.

I'm fairly sure this is how the calculators do this internally. Several years ago, we noted that early versions of the HP-33s did not do rectangular<->polar conversions properly, due to incorrect handling and calculation of angles. I showed that this bug affected the calculation of powers in the complex domain:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=66246#66246

-- KS

Edited: 3 Aug 2008, 12:55 a.m. after one or more responses were posted

Hi Karl

Thanks for your response. The mathematical techniques you have listed are exactly what I used apart from R<->P.

These techniques can be applied in scientific calculators without a complex mode.

Chris

Chris --

The R->P conversion, with its implicit "atan2" function, offers the important advantage of getting the correct quadrant, and handling cases with an x-axis value of zero. Your program, which uses arctangent, will fail for a = 0 (DBZ error) and a < 0 (incorrect quadrant for arctan).

Here's a 30-line program to compute (a + ib)^(x + iy) on an HP-11C or HP-34C without using any storage registers.

This program is also portable to the HP-15C (ensure that flag 8 is clear during execution), but its built-in complex-mode capability is faster and more accurate.

(a)
ENTER
(b)
ENTER
(x)
ENTER
(y)
GSB A

LBL A
RAD
x<>y
->P
Rdn
Rdn
x<>y
->P
LN
->P
x<>y
Rdn
*
Rdn
+
Rup
->R
ex
ENTER
ENTER
Rup
1
->R
Rup
*
x<>y
Rup
*
x<>y
RTN

Three conversions to polar, two conversions to rectangular, and four uses of roll up (saves three roll downs each time). Radians mode is set, and the full stack is used for input and calculations.

Complex multiplication is facilitated by polar mode, but accuracy is slightly compromised (errors in the ninth significant digit for these examples).

-- KS


Edited: 3 Aug 2008, 3:53 p.m. after one or more responses were posted

Karl

Thank you very much for the effort.

Chris

Very nice, I love all-stack solutions and you didn't even need LASTx!

-Katie

Edited: 4 Aug 2008, 10:48 a.m. after one or more responses were posted

Hi, Katie and Chris --

Thank you.

Quote:
I love all-stack solutions...

They do help to ensure compatibility between user programs by not using numbered registers. It's good if the the all-stack solutions don't entail excessive stack manipulation, which is hard to follow.

What made this one possible is complex multiplication by polar mode, which unfortunately cost some accuracy due to all the R<->P convertin'. Rectangular-mode multiplication would have required four registers, by my reckoning.

Quote:
...you didn't even need LASTx!

The last nine lines could have been replaced by

COS
LASTx
SIN
Rup
*
x<>y
Rup
*
RTN

for an ever-so-slight reduction in computation (two internal multiplications by unity). Not relying on LASTx is tidier, because LASTx does not always contain the previous value in x: CHS and CLx (to name several) for good reason do not alter LASTx even as they change the x-register value.

Interesting exercise -- it also sharpened my mathematical understanding of this particular computation.

-- KS

Edited: 3 Aug 2008, 9:21 p.m.