The Museum of HP Calculators

HP Forum Archive 17

 HP 35s: Complex to Rectangular to Polar Revisited (long)Message #1 Posted by Jeff O. on 22 Aug 2007, 7:25 p.m. 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #2 Posted by Alain Mellan on 22 Aug 2007, 8:48 p.m.,in response to message #1 by Jeff O. 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.

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #3 Posted by Jeff O. on 27 Aug 2007, 3:43 p.m.,in response to message #2 by Alain Mellan 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #4 Posted by Arne Halvorsen (Norway) on 27 Aug 2007, 4:11 p.m.,in response to message #3 by Jeff O. 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...

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #5 Posted by Gene Wright on 27 Aug 2007, 5:13 p.m.,in response to message #3 by Jeff O. 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. :-)

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #6 Posted by Karl Schneider on 28 Aug 2007, 12:08 a.m.,in response to message #3 by Jeff O. 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #7 Posted by Jeff O. on 28 Aug 2007, 12:29 p.m.,in response to message #6 by Karl Schneider 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 :-)

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #8 Posted by Trent Moseley on 28 Aug 2007, 2:44 p.m.,in response to message #7 by Jeff O. Hooray! tm

 Re: HP 35s: Complex to Rectangular to Polar Revisited (long)Message #9 Posted by Karl Schneider on 28 Aug 2007, 11:32 p.m.,in response to message #7 by Jeff O. 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited Message #10 Posted by Karl Schneider on 22 Aug 2007, 11:55 p.m.,in response to message #1 by Jeff O. 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited Message #11 Posted by James M. Prange (Michigan) on 23 Aug 2007, 1:20 a.m.,in response to message #10 by Karl Schneider 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited Message #12 Posted by Karl Schneider on 24 Aug 2007, 1:17 a.m.,in response to message #11 by James M. Prange (Michigan) 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited Message #13 Posted by Jeff O. on 23 Aug 2007, 2:13 p.m.,in response to message #10 by Karl Schneider 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

 Re: HP 35s: Complex to Rectangular to Polar Revisited Message #14 Posted by Karl Schneider on 24 Aug 2007, 1:08 a.m.,in response to message #13 by Jeff O. 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

Go back to the main exhibit hall