HP 35s: Complex to Rectangular to Polar Revisited (long)



#10

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

#11

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.


#12

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


#13

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

#14

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

#15

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


#16

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

#17

Hooray!

tm

#18

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

#19

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


#20

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


#21

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

#22

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

#23

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


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP Prime: complex numbers in CAS. Alberto Candel 1 1,895 12-06-2013, 02:36 PM
Last Post: parisse
  [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 3,622 12-05-2013, 07:40 AM
Last Post: cyrille de Brébisson
  HP 35s polar/rectangular conversion CD Dodds 6 2,648 11-28-2013, 02:39 PM
Last Post: Dieter
  17BII & 17BII+ Discounted Payback Period Revisited Tom Neudorfl 8 2,855 11-25-2013, 10:28 AM
Last Post: Don Shepherd
  Touch periodic table on HP Prime - revisited Terje Vallestad 2 1,416 11-23-2013, 11:47 AM
Last Post: Mic
  Complex Number Entry on Prime Jeff O. 19 5,119 11-16-2013, 12:34 PM
Last Post: Jeff O.
  HP Prime: Long integers (continued) Helge Gabert 2 1,501 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  Rectangular to Polar, Polar to Rectangular – One more time Jeff O. 0 1,047 11-06-2013, 11:32 AM
Last Post: Jeff O.
  More programs for polar-rectangular conversion on HP Prime Michael de Estrada 4 1,976 11-04-2013, 12:43 AM
Last Post: Michael de Estrada
  HP Prime: Pass "Long" Integers to a Program Helge Gabert 6 2,439 11-03-2013, 01:12 PM
Last Post: Helge Gabert

Forum Jump: