The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

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:

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

User-friendly complex numbers

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


[ Return to Index | Top of Index ]

Go back to the main exhibit hall