The Incredible HP-35s



#37

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


#38

:-))

Trent, you'll get them with a 15Cx and a 45s. Promised (HTH).

#39

HP-45, 2nd row, 2nd column

1973! Perfect calculators never become obsolete.

#40

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.


#41

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


#42

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


#43

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


#44

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

#45

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.


#46

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


#47

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.


#48

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.

#49

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

#50

[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


#51

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


#52

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


#53

Much nicer. Code can always be improved.

- Pauli


#54

Sure, as here:

LBL P
Rolldown
Rolldown
(EQN) REGZ+i*REGT
ARG
LASTx
ABS
RTN

Cheers, Reth


#55

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


#56

Would you mind placing this conversion routines in the museums software library, Pauli?


#57

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

#58

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


#59

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

#60

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.


#61

Thank you Gene. My fault. It's back to the old axiom "RTB": Read the book.

tm

#62

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


#63

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.


#64

Quote:
Let us go forth and algorithmify.

Very nice... ;)

#65

My algorithmic head is hanging low, nice try folks!

tm

#66

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


#67

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?


#68

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.


#69

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.

#70

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.

#71

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.)
#72

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  NoV-64: The Incredible Shrinking HEPAX RAM Les Wright 31 979 05-27-2012, 08:48 AM
Last Post: M. Joury
  Matrix functions on the WP 34s Build 1685: in a word "incredible" Gene Wright 78 1,465 10-06-2011, 09:16 AM
Last Post: Crawl
  OT: New incredible shuttle video for space (and LED) nerds Egan Ford 3 190 12-13-2010, 09:21 PM
Last Post: Dan W

Forum Jump: