(a + ib)^(x + iy) on HP 15C



#9

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


#10

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.


#11

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.


#12

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

#13

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


#14

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


#15

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


#16

Karl

Thank you very much for the effort.

Chris

#17

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


#18

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  hp-il/hp-ib interface 82169A vs. C Hans Holzach 5 653 07-12-2012, 03:28 PM
Last Post: J-F Garnier
  Photo of my HP 15c | 15c LE DigiGal 2 540 10-12-2011, 12:34 PM
Last Post: DigiGal
  HP 15c LE vs HP-15C dimensions - BOTH ARE HUGE! Joerg Woerner 4 704 10-03-2011, 06:53 AM
Last Post: Jim Johnson
  HP 15C and 15C LE not the same dimensions? Derek 16 1,544 09-30-2011, 05:33 PM
Last Post: Derek
  Original 15C Keyboard Test Works With 15C LE!!! DigiGal 5 858 09-26-2011, 07:33 PM
Last Post: M. Joury
  How would a new HP 15c+ affect 15c market value? megarat 5 704 07-07-2010, 06:48 PM
Last Post: John Stark
  HP-IB Systems Training with the HP-85 as a controller Vassilis Prevelakis 0 269 06-25-2006, 04:08 PM
Last Post: Vassilis Prevelakis
  What can I do with an 82937A? (HP-IB interface for series 80) John Ioannidis 2 398 12-13-2005, 05:42 PM
Last Post: Howard Owen
  HP-IB x IEEE-488 x GPIB Artur-Brazil 4 539 05-15-2005, 02:54 AM
Last Post: Garth Wilson
  an HP-IB card 27209 Patrice 1 275 12-06-2004, 08:45 AM
Last Post: Emmanuel aka xeq41

Forum Jump: