HP Forums

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:

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

User-friendly complex numbers

-- 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,

Thanks for your review and comments.

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

In case anyone is interested, I took Alain's advice and added a jump table. I also changed the order of the routines to make it easier to remember. (I could have done that with the jump table with the original program, but I wanted the routines to be in the same order within the program as the order in which they appear in the jump table.) Unfortunately, I can’t start the jump table with the jump to the first routine at Z001, as that’s where the program label is. I have to start with the jump to routine 1 at label Z002. So remembering which jump goes to which routine would require a mental conversion to remember to add one to the number of the routine, which for me would be bound to result in errors when I subtract one instead of adding. With the reordering of routines, I find it easier to remember that those routines that are “rectangular-centric”, i.e. C=>R, R=>C and R=>P, are the even numbered labels Z002, Z004 and Z006, and the “polar-centric” routines (C=>P, P=>C and P=>R) are the odd labels Z003, Z005 and Z007. (Of course, the definitions of “rectangular-centric” and “polar-centric” are subject to debate, i.e., you might swap my definitions of R=>P and P=>R). Complex Conjugate is the last routine, I’ll just have to remember that it’s no. 8. To help picture things, the jump table is as follows:

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		

Z002	GTO Z009	:jump to Complex to Rectangular

Z003	GTO Z018	:jump to Complex to Polar

Z004	GTO Z026	:jump to Rectangular to Complex

Z005	GTO Z037	:jump to Polar to Complex

Z006	GTO Z048	:jump to Rectangular to Polar

Z007	GTO Z064	:jump to Polar to Rectangular

Z008	GTO Z078	:jump to Complex Conjugate

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

x²

+ / -           (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!

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

Jeff O.

Alain Mellan

Karl Schneider

James M. Prange (Michigan)

Jeff O.

Karl Schneider

Karl Schneider

Jeff O.

Arne Halvorsen (Norway)

Gene Wright

Karl Schneider

Jeff O.

Trent Moseley

Karl Schneider