I'm looking at my 1980's lowend HP31E, 1st column, 4th and 5th rows, and after a yellow shift what do I see: >R and >P. Incredible!
tm
The Incredible HP35s


« Next Oldest  Next Newest »

▼
08072007, 12:44 AM
I'm looking at my 1980's lowend HP31E, 1st column, 4th and 5th rows, and after a yellow shift what do I see: >R and >P. Incredible! tm ▼
08072007, 01:43 AM
:)) Trent, you'll get them with a 15Cx and a 45s. Promised (HTH).
08072007, 03:59 AM
HP45, 2nd row, 2nd column 1973! Perfect calculators never become obsolete.
08072007, 12:58 PM
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
Rectangular to polar: phi ENTER r requiring that the components (x,y) or (r,phi) are entered/obtained in a separated way, i.e. x in xregister, y in yregister, r in xregister, phi in yregister. I would prefer the following solution, retyped directly from my HP35s (regardless of the fact that someone could have already proposed the same in another thread):
LBL P 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. ▼
08072007, 02:30 PM
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 ▼
08082007, 05:16 PM
Preserving Z and T registers can be done using 1 storage register (don't know about speed penalty) and no EQ's
LBL P ▼
08082007, 11:17 PM
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 HP35s". tm
08072007, 03:12 PM
For LBL P, try this:
LBL P 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 Press EQN before the entering the lines containing the REG instructions. Z and T are preserved. ▼
08072007, 03:26 PM
Like what Gene said (untested):
R001 lbl R I really like being able to put stack registers into equations... ccb ▼
08072007, 05:58 PM
Quote: 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. ▼
08072007, 06:53 PM
Quote:
You might use
r = SQRT(x^{2} + y^{2})
Then only a problem occurs for r + x = 0 which means arg = Pi.
08072007, 04:52 PM
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...
08082007, 07:44 PM
[EDIT: I posted an improved version immediately below this message, don't use this code if you want the flag independence  Pauli]
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
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
Checksums and sizes are: LN= checksum I hope somebody finds this useful.  Pauli
Edited: 8 Aug 2007, 11:35 p.m. after one or more responses were posted ▼
08082007, 11:34 PM
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
Checksums and sizes are: LN= checksum  Pauli ▼
08142007, 07:17 AM
Thanks for the code, Paul! I used exactly yours for >P and the following >R:
LBL P Short and Z,T preserving :) ▼
08142007, 04:09 PM
Much nicer. Code can always be improved.  Pauli ▼
08142007, 05:13 PM
Sure, as here: LBL P Cheers, Reth ▼
08142007, 05:55 PM
And wrappering this version up so the setting of flag 10 no longer matters gives us:
P001 LBL P  Pauli ▼
08152007, 02:29 AM
Would you mind placing this conversion routines in the museums software library, Pauli?
08142007, 06:04 PM
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
▼
08142007, 06:08 PM
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
08142007, 09:14 PM
These are mentioned in the learning module: and in the 35s review: They are also mentioned in the printed 35s manual in appendix B on page B7 and also on page 108.
08072007, 03:42 PM
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 ▼
08072007, 05:26 PM
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.
08082007, 07:26 AM
Quote:They instead have directly accessible V\> and \>V2 and \>V3, which are more general versions of the same thing, suitable for also handling complexnumber objects, as well as both 2D and 3D vector objects, none of which formerly existed in older calculators having only individual realvalued stack levels (and no 3D coordinate system conversion at all).
In addition (which to some extent may apply to HP35s),
During all complex (or vector) object display and data entry,
So most of the point of having explicit "conversion" commands on HP48/49/50
But one can use V\> and \>V2 on HP48/49/50
Programs for all HP48/49/50: @ Twolevel input, twolevel output:
Aren't the latter much more convenient (and foolproof) Does the HP35s work in any similar fashion?
Old discussion on comp.sys.hp48:
 Edited: 8 Aug 2007, 5:00 p.m. after one or more responses were posted ▼
08082007, 04:15 PM
Just another spin: How do you convert H.ms to Hrs, and then insert into the polar notation without having to reenter the value? Any ideas? ▼
08082007, 04:49 PM
Quote: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 builtin 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. ▼
08082007, 10:19 PM
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,
Edited: 8 Aug 2007, 11:12 p.m.
08082007, 11:08 PM
Quote:Use \>V2 or \>V3.
Regards, Edited: 8 Aug 2007, 11:12 p.m.
08102007, 08:36 AM
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 rekey in the angle? If so, the following keystrokes will do it: keystroke CommentsThe 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.)
08082007, 10:07 PM
I'll add that \>V2 returns a 2element 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, Edited: 8 Aug 2007, 11:13 p.m. 
Possibly Related Threads...  
Thread  Author  Replies  Views  Last Post  
NoV64: The Incredible Shrinking HEPAX RAM  Les Wright  31  2,045 
05272012, 08:48 AM Last Post: M. Joury 

Matrix functions on the WP 34s Build 1685: in a word "incredible"  Gene Wright  78  3,635 
10062011, 09:16 AM Last Post: Crawl 

OT: New incredible shuttle video for space (and LED) nerds  Egan Ford  3  427 
12132010, 09:21 PM Last Post: Dan W 