I have been looking at the complex mode on my Hp 15C and thought I would develop a program to calculateZ = (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

givingZreal = 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 - ZimagThe 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.00483Any 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/Sand 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)}= e

^{ln[(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)}= e^{c}*e^{jd}

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 ALBL A

RAD

x<>y

->P

Rdn

Rdn

x<>y

->P

LN

->P

x<>y

Rdn

*

Rdn

+

Rup

->R

e^{x}

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. *