HP Forum Archive 17

[ Return to Index | Top of Index ]

The Incredible HP-35s Message #1 Posted by Trent Moseley on 7 Aug 2007, 12:44 a.m. I'm looking at my 1980's low-end HP-31E, 1st column, 4th and 5th rows, and after a yellow shift what do I see: >R and >P. Incredible! tm

Re: The Incredible HP-35s Message #2 Posted by Walter B on 7 Aug 2007, 1:43 a.m., in response to message #1 by Trent Moseley :-)) Trent, you'll get them with a 15Cx and a 45s. Promised (HTH).

Re: The Incredible HP-35s Message #3 Posted by Thomas Radtke on 7 Aug 2007, 3:59 a.m., in response to message #1 by Trent Moseley HP-45, 2nd row, 2nd column 1973! Perfect calculators never become obsolete.

HP-35s ->P and ->R conversions Message #4 Posted by Nenad (Croatia) on 7 Aug 2007, 12:58 p.m., in response to message #1 by Trent Moseley The aim is to establish the procedure for polar/rectangular convrsion that works the same way as on almost any vintage HPcalc Polar to rectangular: y ENTER x ->P (on HP35s: XEQ P ENTER) r x<>y phi Rectangular to polar: phi ENTER r ->R (on HP35s: XEQ R ENTER) x x<>y y requiring that the components (x,y) or (r,phi) are entered/obtained in a separated way, i.e. x in x-register, y in y-register, r in x-register, phi in y-register. I would prefer the following solution, re-typed directly from my HP35s (regardless of the fact that someone could have already proposed the same in another thread): LBL P x<>y i x + ARG LASTx ABS RTN LBL R x<>y COS x<>y LASTx SIN x<>y x x<>y LASTx x RTN Anybody is welcome to improve this. At the end we would have a consensus, containing the best solution we were able to find out together.

Re: HP-35s ->P and ->R conversions Message #5 Posted by Trent Moseley on 7 Aug 2007, 2:30 p.m., in response to message #4 by Nenad (Croatia) That's nice but you lose the contents of the Z and T registers. I know you can store the contents, but then here we go again. tm

Re: HP-35s ->P and ->R conversions Message #6 Posted by Reth on 8 Aug 2007, 5:16 p.m., in response to message #5 by Trent Moseley Preserving Z and T registers can be done using 1 storage register (don't know about speed penalty) and no EQ's LBL P STO D Rv SIN LASTx COS RCL* D X<>Y RCL* D RTN LBL R STO Y Rv i RCL* Y + ARG LASTx ABS RTN Rv here is Roll Down Cheers, Reth

Re: HP-35s ->P and ->R conversions Message #7 Posted by Trent Moseley on 8 Aug 2007, 11:17 p.m., in response to message #6 by Reth Reth, Thank you so much. It's nice to get simple answers to simple questions! I'm looking forward to using your routines in some of my programs tomorrow on the "Incredible HP-35s". tm

Re: HP-35s ->P and ->R conversions Message #8 Posted by Reth on 10 Aug 2007, 3:26 a.m., in response to message #7 by Trent Moseley You're welcome :) BTW I checked and there is no speed penalties for using external storage register so I guess this is the way to go. Cheers, Reth

Re: HP-35s ->P and ->R conversions - updated versions Message #9 Posted by Gene Wright on 7 Aug 2007, 3:12 p.m., in response to message #4 by Nenad (Croatia) For LBL P, try this: LBL P RDN RDN REGZ x i + REGT RUP X<>Y RDN RDN ARG(REGZ) ABS(REGT) RTN Press EQN before the entering the lines containing the REG instructions. Z and T are preserved. Something similar can be done for LBL R. LBL P RDN RDN REGZ x SIN(REGZ) REGT x COS(LastX) RTN Press EQN before the entering the lines containing the REG instructions. Z and T are preserved.

Re: HP-35s ->P and ->R conversions - updated versions Message #10 Posted by Charles Bennett on 7 Aug 2007, 3:26 p.m., in response to message #9 by Gene Wright Like what Gene said (untested): R001 lbl R R002 RDN R003 RDN R004 EQN [ REGT x SIN(REGZ), REGT x COS(REGZ) ] R005 [1,0] R006 x<>y R007 X R008 EQN lastx X [0,1] R009 RTN P001 lbl P P002 RDN P003 RDN P004 EQN [ ATAN(REGT/REGZ), SQRT(SQ(REGT)+SQ(REGZ)) ] P005 GTO R005 I really like being able to put stack registers into equations... ccb

HP-35s ->P and ->R conversions Message #11 Posted by Nenad (Croatia) on 7 Aug 2007, 5:58 p.m., in response to message #10 by Charles Bennett Quote: P004 EQN [ ATAN(REGT/REGZ), SQRT(SQ(REGT)+SQ(REGZ)) ] Appreciating everyone's response it may be noticed that we are obviously moving forward, instead of murmuring against the lack of Pol/Rect conversions in HP35s in an "old fashioned way". In the above quoted equation, would the first vector component lead us into a problem in case REGZ=0 or both REGZ=0 and REGT=0? A single ATAN would not be enough to determine the quadrant of the polar angle? AFAIK, "long long ago in a galaxy far far away" there existed a function ATAN2 instead of ATAN to deal with such a situation. IMHO, it would be great if we finally accept the solution avoiding equations, implementing pure "old fashioned" RPN, but preserving the contents of T and Z registers. I cannot figure out one, yet. Katie, Valentin, Namir, all others - I am certain someone can do it perfectly, to leave this matter behind us.

Re: HP-35s ->P and ->R conversions Message #12 Posted by Thomas Klemm on 7 Aug 2007, 6:53 p.m., in response to message #11 by Nenad (Croatia) Quote: AFAIK, "long long ago in a galaxy far far away" there existed a function ATAN2 instead of ATAN to deal with such a situation. You might use which yields something like: r = SQRT(x2 + y2) y arg = 2*atan(-----) r + x Then only a problem occurs for r + x = 0 which means arg = Pi. However I don't know if it's possible to avoid to calculate r twice.

Re: HP-35s ->P and ->R conversions - updated versions Message #13 Posted by Reth on 7 Aug 2007, 4:52 p.m., in response to message #9 by Gene Wright Well one has to decide what's more important, preserving stack content, speed (given STO & RCL are slower) or necessity of checking/clearing status of flag 10... Cheers, Reth

Re: HP-35s ->P and ->R conversions Message #14 Posted by Paul Dale on 8 Aug 2007, 7:44 p.m., in response to message #4 by Nenad (Croatia) [EDIT: I posted an improved version immediately below this message, don't use this code if you want the flag independence - Pauli] Rectangular Polar conversions aren't something I use but, nonetheless, I thought I'd have a go at this little programming exercise. My program preserves the Z and T stack registers, it honours the current trigonometric mode and handles the degenerate cases. It doesn't do the right thing with LASTx but we can't have everything. At least not yet. It seems to produce the same values as my 15c but I've not tested it extensively. First up the commented programmer friendly listing: 1 # Convert radius, theta -> x, y 2 LBL R # r, t, ?, ? 3 Rv 4 Rv # ?, ?, r, t 5 eqn [REGZ*SIN(REGT),REGZ*COS(REGT)] # [x,y], ?, ?, r 6 unpack: [1,0] # ?, ?, [x, y], [1,0] 7 x<>y 8 * # ., ?, ?, x 9 EQN LASTx*[0,1] 10 RTN 11 12 # Convert x, y -> radius, theta 13 LBL P # x, y, ?, ? 14 x=0? 15 GTO degen 16 Rv 17 Rv # ?, ?, x, y 18 eqn [ATAN(REGT/REGZ),SQRT(SQ(REGT)+SQ(REGZ))] 19 GTO unpack 20 21 # Degenerate cases 22 degen: Rv # y, ?, ?, 0 23 x=0? 24 GTO d2 # 0, ?, ?, 0 25 x>0? 26 1 27 x<0? 28 -1 29 ASIN # t = +/- PI/2, y, ?, ? 30 Rv 31 Rv # ?, ?, t, y 32 eqn [REGZ,ABS(REGT)] # [], ?, ?, t 33 GTO unpack 34 d2: R^ # 0, 0, ?, ? 35 RTN Of course, that isn't a lot of use when entering it into a calculator so here is a calculator friendly version after running though my little assembler: R001 LBL R R002 Rv R003 Rv R004 eqn [REGZ*SIN(REGT),REGZ*COS(REGT)] R005* [1,0] R006 x<>y R007 * R008 EQN LASTx*[0,1] R009 RTN P001 LBL P P002 x=0? P003 GTO P008 P004 Rv P005 Rv P006 eqn [ATAN(REGT/REGZ),SQRT(SQ(REGT)+SQ(REGZ))] P007 GTO R005 P008* Rv P009 x=0? P010 GTO P020 P011 x>0? P012 1 P013 x<0? P014 -1 P015 ASIN P016 Rv P017 Rv P018 eqn [REGZ,ABS(REGT)] P019 GTO R005 P020* R^ P021 RTN where: R^ is roll up Rv is roll down eqn marks the beginning of an equation and shouldn't be entered. Checksums and sizes are: LN= checksum R 74 BE75 P 123 8999 I hope somebody finds this useful. - Pauli Edited: 8 Aug 2007, 11:35 p.m. after one or more responses were posted

Re: HP-35s ->P and ->R conversions Message #15 Posted by Paul Dale on 8 Aug 2007, 11:34 p.m., in response to message #14 by Paul Dale Wouldn't you know it, I thought of another improvement over lunch. In addition to not damaging the stack, this version doesn't care about the status of flag 10 (execute equations or not) and doesn't alter that or any other flag settings. The disadvantage is a couple of extra steps and one more level of subroutine nesting. R001 LBL R R002 FS? 10 R003 GTO R012 R004* Rv R005 Rv R006 eqn [REGZ*SIN(REGT),REGZ*COS(REGT)] R007* [1,0] R008 x<>y R009 * R010 EQN LASTx*[0,1] R011 RTN R012* CF 10 R013 XEQ R004 R014 SF 10 R015 RTN P001 LBL P P002 FS? 10 P003 GTO P024 P004* x=0? P005 GTO P010 P006 Rv P007 Rv P008 eqn [ATAN(REGT/REGZ),SQRT(SQ(REGT)+SQ(REGZ))] P009 GTO R007 P010* Rv P011 x=0? P012 GTO P022 P013 x>0? P014 1 P015 x<0? P016 -1 P017 ASIN P018 Rv P019 Rv P020 eqn [REGZ,ABS(REGT)] P021 GTO R007 P022* R^ P023 RTN P024* CF 10 P025 XEQ P004 P026 SF 10 P027 RTN Checksums and sizes are: LN= checksum R 92 5744 P 141 5301 - Pauli

Re: HP-35s ->P and ->R conversions Message #16 Posted by Thomas Radtke on 14 Aug 2007, 7:17 a.m., in response to message #15 by Paul Dale Thanks for the code, Paul! I used exactly yours for ->P and the following ->R: LBL P Rolldown Rolldown (EQN) REGZ+i*REGT ENTER ARG x<>y ABS RTN Short and Z,T preserving :-)

Re: HP-35s ->P and ->R conversions Message #17 Posted by Paul Dale on 14 Aug 2007, 4:09 p.m., in response to message #16 by Thomas Radtke Much nicer. Code can always be improved. - Pauli

Re: HP-35s ->P and ->R conversions Message #18 Posted by Reth on 14 Aug 2007, 5:13 p.m., in response to message #17 by Paul Dale Sure, as here: LBL P Rolldown Rolldown (EQN) REGZ+i*REGT ARG LASTx ABS RTN Cheers, Reth

Re: HP-35s ->P and ->R conversions Message #19 Posted by Paul Dale on 14 Aug 2007, 5:55 p.m., in response to message #18 by Reth And wrappering this version up so the setting of flag 10 no longer matters gives us: P001 LBL P P002 FS? 10 P003 GTO P011 P004* Rv P005 Rv P006 eqn REGZ+i*REGT P007 ARG P008 LASTx P009 ABS P010 RTN P011* CF 10 P012 XEQ P004 P013 SF 10 P014 RTN - Pauli

Re: HP-35s ->P and ->R conversions Message #20 Posted by Thomas Radtke on 15 Aug 2007, 2:29 a.m., in response to message #19 by Paul Dale Would you mind placing this conversion routines in the museums software library, Pauli?

Re: HP-35s ->P and ->R conversions Message #21 Posted by Paul Dale on 15 Aug 2007, 5:43 p.m., in response to message #20 by Thomas Radtke I'd assumed that the final conversion routines would go there and ti seems like we're there or very close. I'll submit the latest versions presently. - Pauli

Re: HP-35s ->P and ->R conversions Message #22 Posted by Trent Moseley on 14 Aug 2007, 6:04 p.m., in response to message #18 by Reth I don't understand "REGZ" or "REGT". Do you mean "RCL Z" and "RCL T"? I don't see "REZ" in the User's Guide. Thanks, tm

Re: HP-35s ->P and ->R conversions Message #23 Posted by Paul Dale on 14 Aug 2007, 6:08 p.m., in response to message #22 by Trent Moseley In equation mode, press Rv and you'll be greeted with a short menu containing the stack registers. These insert REGX, REGY, REGZ and REGT into the current equation and when executed, they evaluate to the appropriate stack register. A neat way to access the stack from algebraics. - Pauli

REGZ etc Message #24 Posted by Gene Wright on 14 Aug 2007, 9:14 p.m., in response to message #22 by Trent Moseley These are mentioned in the learning module: Accessing the stack registers and in the 35s review: 35s review They are also mentioned in the printed 35s manual in appendix B on page B-7 and also on page 10-8.

Re: REGZ etc Message #25 Posted by Trent Moseley on 14 Aug 2007, 10:57 p.m., in response to message #24 by Gene Wright Thank you Gene. My fault. It's back to the old axiom "RTB": Read the book. tm

Re: The Incredible HP-35s Message #26 Posted by Les Wright on 7 Aug 2007, 3:42 p.m., in response to message #1 by Trent Moseley I note that the HP49G+ and HP50G do not have directly accessible P->R and R->P conversions, though I do understand that they are available as SYSEVAL calls, and there are even extended precision versions in SysRPL for real keeners. But one typically toggles between the rectangular, polar, cylindrical, and spherical renderings of complex numbers and vectors by changing the MODE settings in question. Mmmmm, this does sound a little familiar, does it not? ;) Of course, the 49G, 49G+, and 50G make it very easy to extract the real and complex parts from a complex number, and to decompose a vector or list of any length to its elements. Despite this, the danged 35s is starting to grow on me, and like the great reviewer who shares my surname I am keen to defend its under $60 outsourced Chinese honour. I just wish the thing were as fast as the 33S! Shortly I will post some code that presents much more elegantly and cleanly on the 35S, thanks to line number addressing, but runs so much faster on the 33S, even though with all of the internal jumps and subroutines it gobbles up most of my labels! My first programmable was a TI57. It has the much mourned P<>R conversions too! Les

Re: The Incredible HP-35s Message #27 Posted by Paul Brogger on 7 Aug 2007, 5:26 p.m., in response to message #26 by Les Wright I think it's great to have the 33s' innards in the 35s' wrapper. (And, not to mention, improved in many ways.) Too bad about the P<->R conversions. But hey! It's programmable. Let us go forth and algorithmify.

Re: The Incredible HP-35s Message #28 Posted by Vincze on 7 Aug 2007, 9:13 p.m., in response to message #27 by Paul Brogger Quote: Let us go forth and algorithmify. Very nice... ;)

Re: The Incredible HP-35s Message #29 Posted by Trent Moseley on 7 Aug 2007, 10:05 p.m., in response to message #28 by Vincze My algorithmic head is hanging low, nice try folks! tm

Re: The Incredible HP-35s Message #30 Posted by John H Meyers on 8 Aug 2007, 7:26 a.m., in response to message #26 by Les Wright Quote: I note that the HP49G+ and HP50G do not have directly accessible P->R and R->P conversions They instead have directly accessible V\-> and \->V2 and \->V3, which are more general versions of the same thing, suitable for also handling complex-number objects, as well as both 2D and 3D vector objects, none of which formerly existed in older calculators having only individual real-valued stack levels (and no 3D coordinate system conversion at all). In addition (which to some extent may apply to HP35s), all HP48/49/50 can display complex and vectors (both 2D and 3D) automatically as "polar," to full precision, by simply changing display mode to CYLIN/SPHERE, and can convert polar coordinates to rectangular automatically, as they are being entered. During all complex (or vector) object display and data entry, an angle symbol prefixes each angular value, unmistakably eliminating ambiguity. So most of the point of having explicit "conversion" commands on HP48/49/50 can be considered unnecessary -- the "polar" coordinates are always external (on the display or in the data entry area), the internal objects remain rectangular always, and can always be added etc. without conversions, as well as without risk of forgetting which mode the coordinates are in, nor accidentally adding the polar coordinates, etc. But one can use V\-> and \->V2 on HP48/49/50 to get the same effect as old P->R and R->P anyway; when you do this, however, you can no longer freely add objects when they have been internally changed to polar coordinates, and you no longer have unambiguous angle symbols that prevent misinterpretation (or forgetting in which state you left the results, or repeating the same conversion twice the same way, instead of undoing it). Programs for all HP48/49/50: @ Two-level input, two-level output: @ real x, real y <==> real r, real theta \<< -16 SF \->V2 -16 CF V\-> \>> 'P\->R' STO \<< -16 CF \->V2 -16 SF V\-> \>> 'R\->P' STO @ One-level input, one-level output (Vector or Complex): @ [real x, real y] <==> [real r, real theta] @ (real x, real y) <==> (real r, real theta) \<< V\-> -16 SF \->V2 -16 CF \>> 'p\->r' STO \<< -16 SF V\-> -16 CF \->V2 \>> 'r\->p' STO @ Note that you must keep flag -16 always cleared @ Programs to use whichever of the above @ applies to the type of object(s) on the stack: \<< IF DUP TYPE OVER TYPE 28 \=/ AND THEN p\->r ELSE P\->R END \>> 'PtoR' STO \<< IF DUP TYPE OVER TYPE 28 \=/ AND THEN r\->p ELSE R\->P END \>> 'RtoP' STO @ But often we want only to be able to display either way, @ or to toggle back & forth, as was thoughtfully provided @ by the POLAR keyboard command on the HP48[S/G][X/+] @ which affects all complex numbers, or 2D/3D vectors: \<< -16 DUP IF FS? THEN CF ELSE SF END \>> 'P~R' STO @ Note that nothing is really converted internally at all here, @ but only changes appearance in the display, and also note @ that *all* stack objects change appearance simultaneously! @ Here is the corresponding RAD[ian] angle mode toggle, @ which again converts nothing internally, but only changes @ the units in which angles are displayed or initially entered: \<< -17 DUP IF FS? THEN CF ELSE SF END \>> 'D~R' STO Aren't the latter much more convenient (and foolproof) than the way things used to be done? Does the HP35s work in any similar fashion? Old discussion on comp.sys.hp48: http://groups.google.com/group/comp.sys.hp48/msg/443f73ec50a1bd67?dmode=source -- Edited: 8 Aug 2007, 5:00 p.m. after one or more responses were posted

Re: The Incredible HP-35s Message #31 Posted by SMcmullin on 8 Aug 2007, 4:15 p.m., in response to message #30 by John H Meyers Just another spin: How do you convert H.ms to Hrs, and then insert into the polar notation without having to re-enter the value? Any ideas?

Re: The Incredible HP-35s Message #32 Posted by John H Meyers on 8 Aug 2007, 4:49 p.m., in response to message #31 by SMcmullin Quote: Just another spin: How do you convert H.ms to Hrs, and then insert into the polar notation without having to re-enter the value? That's obviously one of the special cases in which you do need to separately convert dd.mmss to pure degrees, and then combine it with the other coordinate -- or create a program to do it for you. The issue is specific to the degrees angular mode, and has no counterpart in radian or grad angle mode, so it is not surprising that there is no single built-in command for it; calcs that have a "dms" key that does "on the fly" conversion while typing might be able to accommodate this anyway, but even that style of data entry has its own pitfalls to consider.

48/49 series polar/rectangular conversions Message #33 Posted by James M. Prange (Michigan) on 8 Aug 2007, 10:19 p.m., in response to message #32 by John H Meyers I suppose that, if it would fit into ROM, it would have been possible to include a D.MMSSs, and even a D.MMm angular mode (in addition to the radian, (decimal) degree, and grad modes), but apparently the developers felt that the HMS\->, \->HMS, HMS+, and HMS- commands sufficed. Regards, James Edited: 8 Aug 2007, 11:12 p.m.

48/49 series polar/rectangular conversions Message #34 Posted by James M. Prange (Michigan) on 8 Aug 2007, 11:08 p.m., in response to message #31 by SMcmullin Quote: Just another spin: How do you convert H.ms to Hrs, and then insert into the polar notation without having to re-enter the value? Any ideas? Use \->V2 or \->V3. Regards, James Edited: 8 Aug 2007, 11:12 p.m.

Re: The Incredible HP-35s Message #35 Posted by Jeff O. on 10 Aug 2007, 8:36 a.m., in response to message #31 by SMcmullin I may have missed the point of this thread, but are you asking how to convert an angle in H.MS format to decimal degrees, then get that as the angular portion of a complex number on the 35s (i.e., not the 48, 49 or 50) without having to key in a magnitude, press theta, then re-key in the angle? If so, the following keystrokes will do it: keystroke Comments HMS-> Converts your H.MS angle to decimal degrees ->RAD Converts decimal degrees to radians i the i key, 2nd row, 4th key * multiply ex raise e to the power of the value in the x register The above will give you a complex number with a magnitude of 1 at your original angle. If you have a magnitude hanging around that you wanted as part of this complex number, enter that and multiply to get a complex number with that magnitude at your original angle. (Credit to Les for presenting this technique in this message.)

48/49 series polar/rectangular conversions Message #36 Posted by James M. Prange (Michigan) on 8 Aug 2007, 10:07 p.m., in response to message #30 by John H Meyers I'll add that \->V2 returns a 2-element vector if flag -19 is clear, or a complex number if flag -19 is set. Also, V\-> can be used to convert a complex number to a pair of real numbers, respecting the coordinate system and angular modes, regardless of the state of flag -19, as well as for converting a vector to reals. Note that since vectors and complex numbers are always stored using rectangular coordinates, approximations due to rounding may apply when converting to or from polar coordinates, including when editing a complex number or vector when in polar mode. For example: [ 1. 1. ] DEG CYLIN displays [ 1.41421356237 \<)45. ], and V\-> on that returns 1.41421356237 and 45., and \->V2 on those returns [ 1.41421356237 \<)45. ], but now RECT displays [ .999999999998 .999999999998 ] instead of the original vector. Another example: Enter [ 1. 1. ] DEG CYLIN to display [ 1.41421356237 \<)45. ], then execute EDIT to put [ 1.41421356237 \<)45. ] in the command line, then press ENTER to put it back on the stack, and RECT will show it as [ .999999999998 .999999999998 ] instead of the original vector. The second example also applies to ASCII (Text) mode transfers from and back to the calculator. Regards, James Edited: 8 Aug 2007, 11:13 p.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall