# HP Forums

You're currently viewing a stripped down version of our content. View the full version with proper formatting.

The absence of rectangular to polar, polar to rectangular and related functions on the HP 35s has already been discussed at length, and I believe that various routines are due to soon be included in the software library. Rather than wait, I attempted to go through the various threads to see if I could pull out the best routines for each function. However, I found it a bit tricky to follow the threads and various routines that were presented. To try to get a handle on things, I went back to the basics of the problem and tried to work my way forward. The following likely rehashes a lot of the previous discussion, and I make no claims of originality. So, at the risk of beating a dead horse (and exposing a blatant lack of understanding of some point or another), from the beginning.....

As I see things, there are seven basic functions related to the entry, display and conversion of complex numbers that the 35s lacks. For the sake of the following discussion, “Complex” means a complex number residing in a single stack level on the 35s, “Real Rectangular” means a complex number represented in rectangular form as two real values in two stack levels, and “Real Polar” means a complex number represented in polar form as two real values in two stack levels. The seven missing functions are:

1. Complex to Real Rectangular Form conversion - Decomposition of a complex number into its real and imaginary components, with those values placed in the stack x and stack y registers, respectively.

2. Complex to Real Polar Form conversion - Decomposition of a complex number into the magnitude and angle of its polar form, with those values placed in the stack x and stack y registers, respectively.

3. Real Rectangular Form to Complex conversion - Formation of a complex number in stack x from real and imaginary components initially in the stack x and stack y registers, respectively.

4. Real Polar Form to Complex conversion - Formation of a complex number in stack x from a magnitude and angle initially in the stack x and stack y registers, respectively.

5. Real Polar to Real Rectangular Conversion - Conversion of a polar representation of complex number in stack x (magnitude) and stack y (angle) to a rectangular representation in stack x (real) and stack y (imaginary).

6. Real Rectangular to Real Polar Conversion - Conversion of a rectangular representation of complex number in stack x (real) and stack y (imaginary) to a polar representation in stack x (magnitude) and stack y (angle).

7. Complex Conjugate - Conversion of a complex number in stack x to its complex conjugate in stack x.

Ideally, routines to perform the above functions would leave the stack (including Last x) exactly as if they were built in functions. Before discussion of how they should operate, a few definitions are in order:
```Re        :a value representing the real component of a complex number
Im        :a value representing the imaginary component of a complex number
Mag       :a value representing the magnitude of a complex number when
expressed in polar form
Ang       :a value representing the angle of a complex number when
expressed in polar form
A, B, C   :specific pre-existing values in the stack
Re i Im   :a complex number held in a single stack level displayed in
rectangular form
Mag / Ang :a complex number held in a single stack level displayed in
polar form
--        :the most recent value in the Last x register, to be overwritten
```
With the above said, I believe that the previously described seven functions should perform as follows:
```1.  Complex to Real Rectangular
Stack Before 			        Stack After
t:	C		           ->	     t:	B
z:	B		       	   ->	     z:	A
y:	A	 		   ->	     y:	Im
x:	Re i Im or Mag / Ang       ->	     x:	Re
Last x:	--		       	   ->	Last x:	Re i Im or Mag / Ang
2.  Complex to Real Polar
Stack Before 			        Stack After
t:	C		           ->	     t:	B
z:	B		       	   ->	     z:	A
y:	A	 		   ->	     y:	Ang
x:	Re i Im or Mag / Ang       ->	     x:	Mag
Last x:	--		       	   ->	Last x:	Re i Im or Mag / Ang
3.  Real Rectangular to Complex
Stack Before 			        Stack After
t:	B		           ->	     t:	B
z:	A		       	   ->	     z:	B
y:	Im	 		   ->	     y:	A
x:	Re 			   ->	     x:	Re i Im or Mag / Ang
Last x:	--		       	   ->	Last x:	Re
4.  Real Polar to Complex
Stack Before 			        Stack After
t:	B		           ->	     t:	B
z:	A		       	   ->	     z:	B
y:	Ang	 		   ->	     y:	A
x:	Mag			   ->	     x:	Re i Im or Mag / Ang
Last x:	--		       	   ->	Last x:	Mag

5.  Real Polar to Real Rectangular
Stack Before 			        Stack After
t:	B		           ->	     t:	B
z:	A		       	   ->	     z:	A
y:	Ang	 		   ->	     y:	Im
x:	Mag			   ->	     x:	Re
Last x:	--		       	   ->	Last x:	Mag
6.  Real Rectangular to Real Polar
Stack Before 			        Stack After
t:	B		           ->	     t:	B
z:	A		       	   ->	     z:	A
y:	Im	 		   ->	     y:	Ang
x:	Re			   ->	     x:	Mag
Last x:	--		       	   ->	Last x:	Re
7.  Complex Conjugate
Stack Before 			        Stack After
t:	C		           ->	     t:	C
z:	B		       	   ->	     z:	B
y:	A	 		   ->	     y:	A
x:	Re i Im or Mag / Ang       ->	     x:	Re i -Im or Mag/ -Ang
Last x:	--		       	   ->	Last x:	Re i Im or Mag / Ang
```
Having come this far, I went ahead and developed seven routines to accomplish the above functions. I used many ideas and techniques developed in the previous discussion, and I don’t know if I exactly replicated any of the routines presented previously. If so, due credit is given to the original developer. I decided to place them all under one label, rather than having different labels for each. (In earlier threads, I found the labelling a bit confusing. Does Label P convert to Polar, from Polar, convert a complex number to real polar form, etc.?) I chose Label Z, for a couple of reasons. I intend for the program to be always resident on the calculator. Since Z is the last label alphabetically, I can easily remember that it is unavailable for general programming. Also, the letter Z is used to represent complex impedance in electric power engineering, which is my primary application for these functions, so it seemed natural to use it for this suite of functions. Each routine has an equation at the beginning that labels the function to be performed. It is set up to pause, display the function name, then execute the routine when each routine is called. It is not independent of flag 10, which is set to display the function label, then cleared in each routine. So flag 10 will be cleared after each routine, regardless of its setting prior to execution. The routines use only stack manipulation and equations, no general storage registers are used. With the above caveats, my program to implement the suite of Complex-Rectangular-Polar functions is as follows:
```Z001	LBL Z
Z002	SF 10			:Entry point for Complex to Rectangular
Z003	Eqn CPLX->RECT
Z004	PSE
Z005	CF 10
Z006	ABS
Z007	CLx
Z008	eqn ABS(LASTx)*SIN(ARG(LASTx))
Z009	eqn ABS(LASTx)*COS(ARG(LASTx))
Z010	RTN
Z011	SF 10			:Entry point for Complex to Polar
Z012	Eqn CPLX->POLAR
Z013	PSE
Z014	CF 10
Z015	ARG
Z016	LASTx
Z017	ABS
Z018	RTN
Z019	SF 10			:Entry point for Rectangular to Complex
Z020	Eqn RECT->CPLX
Z021	PSE
Z022	CF 10
Z023	ABS
Z024	Roll down
Z025	Roll down
Z026	Eqn LASTx+i*REGT
Z027	Eqn REGZ
Z028	Roll down
Z029	RTN
Z030	SF 10			:Entry point for Polar to Complex
Z031	Eqn POLAR->CPLX
Z032	PSE
Z033	CF 10
Z034	ABS
Z035	Roll Down
Z036	Roll Down
Z037	Eqn LASTx*COS(REGT)+i*LASTx*SIN(REGT)
Z038	Eqn REGZ
Z039	Roll Down
Z040	RTN
Z041	SF 10			:Entry point for Polar to Rectangular
Z042	Eqn POLAR->RECT
Z043	PSE
Z044	CF 10
Z045	ABS
Z046	Roll Down
Z047	Roll Down
Z048	Eqn LASTx*COS(REGT)+i*LASTx*SIN(REGT)
Z049	ENTER
Z050	Roll Down
Z051	Roll Down
Z052	Eqn ABS(REGZ)*SIN(ARG(REGZ))
Z053	Eqn ABS(REGT)*COS(ARG(REGT))
Z054	RTN
Z055	SF 10			:Entry point for Rectangular to Polar
Z056	Eqn RECT->POLAR
Z057	PSE
Z058	CF 10
Z059	ABS
Z060	CLx
Z061	LASTx
Z062	Roll Down
Z063	Roll Down
Z064	Eqn REGZ+i*REGT
Z065	ENTER
Z066	Roll Down
Z067	Roll Down
Z068	Eqn ARG(REGT)
Z069	Eqn ABS(REGT)
Z070	RTN
Z071	SF 10			:Entry point for Complex Conjugate
Z072	Eqn CPLX CONJUGATE
Z073	PSE
Z074	CF 10
Z075	ABS
Z076	CLx
Z077	Eqn SQ(ABS(LASTx))/LASTx
Z078	RTN ```
And, for what it’s worth,

CK = F440

LN = 541

Great work!

One minor comment though: I would add a jump table at the beginning:

```Z001 LBL Z
Z002 GTO Z019
Z003 GTO Z028
...
```

This way, it's easier to remember what is what. XEQ Z002 for the first conversion, Z003 for the second, etc.

Hi, Jeff --

Pretty good work. I fundamentally agree with what you stated, but your functional specifications differ from what has been implemented previously.

Mostly, you are describing the complex-number composition/decomposition functions "R->C" and "C->R" on the RPL-based models. These are quite similar to the vague "COMPLEX" function on the HP-42S, but I've noted a subtle but very important difference:

On the HP-48/49 models, "R->C" and "C->R" assume arguments in rectangular form:

```3 ENTER 4 ENTER R->C
```

will always compose 3+i4. If the calc is in polar mode, it will display that value in polar form.

However, on the HP-42S in polar mode,

```3 ENTER 4 COMPLEX ("R->C")
```

will compose

```3 /4
```

This is the way it ought to work.

Note that the imaginary part is in the x-register and the real part is in the y-register for both RPL models and the HP-42S.

I plan to prepare a detailed short paper about complex numbers and other issues related to improvement of the HP-35s, and deliver it to HP prior to the HHC conference. I hope to get an opportunity for private discussion with HP's calc team during the visit.

Here's the basis of the complex-number discussion, consisting of one exchange between you and me, three years ago:

-- KS

Quote:
On the HP-48/49 models, "R->C" and "C->R" assume arguments in rectangular form:

```3 ENTER 4 ENTER R->C
```

will always compose 3+i4. If the calc is in polar mode, it will display that value in polar form.

True, that's how the 48/49 series works, and it's never seemed quite right to me either.

However, for something that works as you'd like R\->C to work, set flag -19 and use \->V2 instead, and for something that works as you'd like C\->R to work, use V\-> instead.

You could write a program:

```%%HP: T(3);
\<<
RCLF
ROT ROT @ or 3 ROLLD, or, on the 49 series UNROT
-19 SF
\->V2
SWAP
STOF
\>>
```
as a replacement for the R\->C command and name it whatever you want. On the 49 series, you could use either the filer's RENAME operation to change its name to C\->R, or use the development library's S~N operation to create an otherwise invalid name from a string.

On either the 48 or 49 series, to create an otherwise invalid name from a string, you could use the SYSEVAL command with the entry point for the SysRPL \$>ID command. For reference, this would be #5B15h SYSEVAL for both the 48 and 49 series.

For the C\->R command, you could write the program:

```%%HP: T(3);
\<<
V\->
\>>
```
and using the same techniques, rename or store it with the name C\->R.

Of course, when keying in a complex number within the ( ) complex numbers delimiters on the command line (or other source code, such as an ASCII file or a string to be compiled), it's treated as polar notation if the angle symbol is used, or rectangular notation if any other separator is used.

Regards,
James

Karl,

Quote:
...your functional specifications differ from what has been implemented previously.

Agreed, they do differ from the manner in which a complex value is "built" from two stack levels in the 15C, 42S and RPL models. If that is the only way to get a complex number into the calculator, I whole-heartedly approve of keying in real, then imaginary or magnitude, then angle and then executing the function to build the complex number. However, my routines are not intended for use to enter complex numbers in which the components are to be keyed in. The i and theta keys (of which we were long, I'll say pioneering, proponents) allow you to just key them in. No need to put them into stack registers and build the complex number. My routines are for cases where through some sequence of calculations you end up with values in the stack x and stack y registers that represent the real and imaginary components or magnitude and angle of a complex number. You don’t want to have to re-key in those numbers (which would likely require writing one of them down) to get them into complex form. For this situation, I chose the convention that the imaginary component (or angle) goes in stack y, and the real component (or magnitude) goes in stack x. This conforms to the “classic” conventions used for the Rectangular to Polar and Polar to Rectangular functions on every hp calculator with those functions since they were introduced on the HP-45. I then used that convention for all of the functions to which it applied. In any case, if you prefer the other convention, my routines could be easily modified.

I agree that the 42S did things the right way, especially as compared to the RPL models and entry of polar form numbers. The 42S figured you knew what you were doing, i.e., if it was in polar mode, whatever you entered was considered to be in polar form. Of course if you were in polar mode and had a rectangular form number to enter, you could do so, then execute ->POL. Again, the 42S figured you knew what you were doing and dutifully performed the conversion using the components of the complex number treated as Real and Imaginary even though they were displayed as Magnitude and Angle. (I’m quite sure you are aware of all this Karl, I’m just providing a complete answer.) In any case, this situation is also made moot by the i and theta keys.

Quote:
I plan to prepare a detailed short paper about complex numbers and other issues related to improvement of the HP-35s, and deliver it to HP prior to the HHC conference. I hope to get an opportunity for private discussion with HP's calc team during the visit.

I look forward to seeing that paper (assuming you will make it public here or at the conference) and I hope you get HP’s ear. I certainly remember our previous exchanges. While I would still like to see your original or a similar proposal implemented, the 35s is about 80 to 90% of the way there for me. If it had the seven functions I presented, the SHOW function presented the full precision of both components in the two lines of the display, and my Option 3 angle symbol (like the 42S) was used to separate the magnitude from the angle in the display, I’d be pretty well satisfied.

Best Regards,

Jeff

Hi, Jeff --

All in all, it's probably a good idea to redefine "R->C" and "C->R" as you specified. There's no pressing need for consistency with the methods of the HP-42S and HP-48/49 (I can't speak for the HP-50). With your definition, the following sequences would give the same results for converting 3+i4 to polar form as a pair of reals and as a complex (rectangular input mode assumed):

```3 ENTER 4 x<>y ->POL
3 ENTER 4 x<>y R->C ->POL C->R
```

Quote:
The 42S figured you knew what you were doing, i.e., if it was in polar mode, whatever you entered was considered to be in polar form. Of course if you were in polar mode and had a rectangular form number to enter, you could do so, then execute ->POL. Again, the 42S figured you knew what you were doing and dutifully performed the conversion using the components of the complex number treated as Real and Imaginary even though they were displayed as Magnitude and Angle.

Hmm, perhaps that's the reason that ->REC and ->POL operating on a complex number didn't change between "i" and "angle symbol" appropriately. I'd always felt that it was a bug or oversight. However, since the HP-42S offered no means of directly entering a complex number of the form opposite of its current mode setting, then the value-changing conversion was indeed useful. The alternatives were to change mode twice, or to convert a pair of reals with appropriate x< >y.

Quote:
I look forward to seeing that paper (assuming you will make it public here or at the conference)

My planned approach was to submit the paper privately to HP, in order to give them a chance to review and respond. I might make it generally available after the conference. I probably won't have it done in time to meet the deadline for presentation, anyway.

-- KS

James --

Good to hear from you, and thanks for the informative response. It's always helpful to be shown how something might be approached in RPL, because many of us -- it must be admitted -- wouldn't have a clue...

-- KS

```Complex to Real Rectangular Form	C=>R  :	XEQ Z002
Complex to Real Polar Form            	C=>P  :	XEQ Z003
Real Rectangular to Complex         	R=>C  :	XEQ Z004
Real Polar to Complex                  	P=>C  :	XEQ Z005
Real Rectangular to Real Polar        	R=>P  :	XEQ Z006
Real Polar to Real Rectangular 		P=>R  :	XEQ Z007
Complex Conjugate			C=>C* :	XEQ Z008
Rectangular-centric routines shown bold
Polar-centric routines shown in italics
```
The new code listing is as follows:
```Z001	LBL Z
Z009	SF 10		:Entry point for Complex to Rectangular
Z010	Eqn CPLX->RECT
Z011	PSE
Z012	CF 10
Z013	ABS
Z014	CLx
Z015	eqn ABS(LASTx)*SIN(ARG(LASTx))
Z016	eqn ABS(LASTx)*COS(ARG(LASTx))
Z017	RTN
Z018	SF 10		:Entry point for Complex to Polar
Z019	Eqn CPLX->POLAR
Z020	PSE
Z021	CF 10
Z022	ARG
Z023	LASTx
Z024	ABS
Z025	RTN
Z026	SF 10		:Entry point for Rectangular to Complex
Z027	Eqn RECT->CPLX
Z028	PSE
Z029	CF 10
Z030	ABS
Z031	Roll down
Z032	Roll down
Z033	Eqn LASTx+i*REGT
Z034	Eqn REGZ
Z035	Roll down
Z036	RTN
Z037	SF 10		:Entry point for Polar to Complex
Z038	Eqn POLAR->CPLX
Z039	PSE
Z040	CF 10
Z041	ABS
Z042	Roll Down
Z043	Roll Down
Z044	Eqn LASTx*COS(REGT)+i*LASTx*SIN(REGT)
Z045	Eqn REGZ
Z046	Roll Down
Z047	RTN
Z048	SF 10		:Entry point for Rectangular to Polar
Z049	Eqn RECT->POLAR
Z050	PSE
Z051	CF 10
Z052	ABS
Z053	CLx
Z054	LASTx
Z055	Roll Down
Z056	Roll Down
Z057	Eqn REGZ+i*REGT
Z058	ENTER
Z059	Roll Down
Z060	Roll Down
Z061	Eqn ARG(REGT)
Z062	Eqn ABS(REGT)
Z063	RTN
Z064	SF 10		:Entry point for Polar to Rectangular
Z065	Eqn POLAR->RECT
Z066	PSE
Z067	CF 10
Z068	ABS
Z069	Roll Down
Z070	Roll Down
Z071	Eqn LASTx*COS(REGT)+i*LASTx*SIN(REGT)
Z072	ENTER
Z073	Roll Down
Z074	Roll Down
Z075	Eqn ABS(REGZ)*SIN(ARG(REGZ))
Z076	Eqn ABS(REGT)*COS(ARG(REGT))
Z077	RTN
Z078	SF 10		:Entry point for Complex Conjugate
Z079	Eqn CPLX CONJUGATE
Z080	PSE
Z081	CF 10
Z082	ABS
Z083	CLx
Z084	Eqn SQ(ABS(LASTx))/LASTx
Z085	RTN
```
LN=562

Edited to correct the error that Gene kindly pointed out :-)

Edited: 27 Aug 2007, 10:04 p.m. after one or more responses were posted

I realy love to read these posts from people who are posting HP-35s code being one who's is in the mail (Samson just confirmed it on the way). I am programming it in my head and notebook, but last time I did keystroke programming where on a HP-41CV 20 years ago...

Of course, lines Z002 through Z008 are GTO Z009, GTO Z018, etc.

Just for any newbies who read this post and wonder how to put a GTO 9 into the program. :-)

Hi, Jeff --

I haven't tested it yet, but it looks like fine work. Other functions to include might be:

• "Re" (complex number replaced with its real part)
• "Im" (complex number replaced with its imaginary part)
• "Neg" (negate both rectangular parts or shift the angle by a half-circle)

Let's all not forget, though: These are functions that should have been built-in. I aim to convince HP to rectify the matter with an HP-35sII or HP-45s.

-- KS

Hi Karl,

Yes, I considered the Re and Im functions, but then I would have to remember nine jump labels! Seriously, since those are easily obtainable after executing a C=>R conversion, I guess I did not feel a great need to create routines that would provide just the real or just the imaginary part while preserving the stack and Last x. However, if a group of conversions is included on a future model, by all means Re and Im should be included. As for a "Neg" function, doesn't the + / - key do as you suggest (negate both rectangular parts or shift the angle by a half-circle)? Do we need a "Neg Re" key to negate just the real part, i.e., do to the real component what complex conjugate does to the imaginary? I found that it can be accomplished using almost the same technique that you presented for complex conjugate, as follows:

```ENTER
ABS
x2
+ / -           (new step)
x<>y
/```

Regardless of how it is done, does the act of negating the real part of a complex number have a name or any utility in complex number operations?

Quote:
Let's all not forget, though: These are functions that should have been built-in. I aim to convince HP to rectify the matter with an HP-35sII or HP-45s

Yes, they certainly should have. As far as a 35sII, from what Gene says, the 35s absolutely maxed out the architecture (or whatever) of the original 32s platform, such that adding new functions would require deleting others. If we adopt "Re", "Im" and "Neg Re", that makes 10 functions, which can conveniently be grouped as 5 complementary functions that would make good yellow-shift/blue-shift combinations. Hmmm, where can we find five keys with 10 functions that we don't need? Oh yeah, how about the mostly useless SI to English conversions that use up the yellow and blue shifted functions on 5 keys, plus the ROM space required to implement them? Implementation might look like this:

Feel free to use the above in your pitch to hp :-)

Hooray!

tm

Hi, Jeff --

Quote:
As for a "Neg" function, doesn't the + / - key do as you suggest (negate both rectangular parts or shift the angle by a half-circle)?

Hmm, I guess it does. The HP-28C has a "NEG" function that negates both parts of a complex number, just as CHS does. Without checking the manual, I'm not sure why it was provided. "NEG" notwithstanding, the HP-28 offers a fine example of a utility-function menu for complex numbers.

Quote:
Do we need a "Neg Re" key to negate just the real part, i.e., do to the real component what complex conjugate does to the imaginary?

Nah, I doubt it. No practical application comes to mind.

-- KS