The Museum of HP Calculators

HP Forum Archive 18

[ Return to Index | Top of Index ]

35s: Using STO in EQN in RPN program
Message #1 Posted by Matt Draper on 4 Oct 2008, 2:33 p.m.

I've always enjoyed reading this forum. Thank you all for the priceless exchange of ideas and information, and for the good company these past few years.

I got my 35s a week ago, and I've really been enjoying it. Looking through the archives I was surprised to learn that STO can be used in an equation, since the Operation Index in the User's Guide does not indicate that this function can be used in an equation. Coming from the 11C and 42S, this whole business of using equations in an RPN program is very new and interesting to me, and learning that it's possible to use STO in an equation is even more of an eyebrow-raiser. I was also excited to read about using an equation in a program to emulate the stack-preserving behavior of built-in functions.

After spending a few days putting together useful programs for my everyday calculations, I decided it might be fun to tinker with equations in an RPN program. I wondered if it was possible to write a single equation that stores the contents of the stack registers into a series of indirect variables. Arne wrote a straight RPN routine that does a nice job at this, but I wanted to see if I could do it in an equation. This is what I came up with:

A001 LBL A
A002 5>I>(I)-1>I*0+LASTx>(I)*0>I+REGX>(I)*0+1>I*0+REGY>(I)*0+2>I*0+REGZ>(I)*0+3>I*0+REGT>(I)
A003 Rv
A004 RTN

Where ">" is STO, and "-" is the minus operator, not CHS.

I know it looks weird, but it actually works. The first part of the equation, "5>I>(I)", stores a non-zero value (5) in variable 005 to ensure adequate memory allocation for the registers in the event that variable 004 ends up holding a zero value. The rest of it stores REGX, REGY, REGZ, REGT, and LASTx into variables 000, 001, 002, 003, and 004, respectively.

The equation ultimately evaluates to the initial value of REGT, which it dutifully pushes onto the stack. Aside from pushing REGT, it doesn't mess with the stack or LASTx at all, so following it up with a RollDown leaves the stack and LASTx in their initial state.

Any ideas for simplifying or speeding up the equation?

I'm presenting this more as a curiosity than something you might want to actually use, since it's much faster, not to mention easier to read, to do it the straight RPN way. Besides, it might make your screen tilt if you use it too much ;)

      
Re: 35s: Using STO in EQN in RPN program
Message #2 Posted by Andrew Nikitin on 4 Oct 2008, 4:43 p.m.,
in response to message #1 by Matt Draper

Hi, Matt.

I think STO operation in equations is mentioned in user manual that comes on a CD with a calculator.

Page 13-3 discusses using STO in programming in ALG mode and example program on page 17-9 uses saving intermeditate and final values in expressions within RPN program.

I admit that it requires certain mental effort to find and recognize it, but so does programming in general, so it must be ok.

On the program itself, it will not work if stack contains vectors. Vectors (and to slightly lesser extent, complex numbers) are somewhat dysfunctional in 35s, but still usable so you cannot just dismiss them.

Speeding the program up would require significantly shortening it. It seem that time needed to execute an algebraic expression is roughly prorortional to its length. And there is no obvious way to make original expression shorter: you must mention REGX, REGY, REGZ, REGT, LASTx at least once, eacho of them must be accompalined bye >>(I), "*0+" seems like pretty compact way to get rid of previous results.

            
Re: 35s: Using STO in EQN in RPN program
Message #3 Posted by Matt Draper on 4 Oct 2008, 9:24 p.m.,
in response to message #2 by Andrew Nikitin

Thanks Andrew,

I see where I went wrong in skipping over all the ALG mode stuff in the manual. Since my 35s will probably spend its entire life in RPN mode, I just stuck my fingers in my ears and said "RPN, RPN, RPN, la, la, la... I can't hear you!" whenever I saw "In ALG mode" in the manual. But now I understand that even while entering a program in RPN mode, any time I am bold enough to press EQN I've gone over to the "other" side, even if it's only till I find my way back to the big ENTER key. The manual is clear enough about how STO works in ALG mode, but I didn't realize that it sometimes applies to me in RPN mode too.

I didn't think to test the program with anything other than real numbers on the stack. I see that it fails with either vectors or complex numbers on the stack... darn. With complex numbers, it looks like it fails because a complex ends up in variable I (such as 7i7 * 0 = 0i0), which makes an invalid indirect address. With a vector in LASTx (say [3,3]), it fails even earlier, when it tries to compute 0 + [3,3]. I had a good time learning what doesn't work though. Back to straight RPN for stack saving, methinks.

                  
Re: 35s: Using STO in EQN in RPN program
Message #4 Posted by Gene Wright on 4 Oct 2008, 9:34 p.m.,
in response to message #3 by Matt Draper

Well, this is mentioned in the 35s review written for Datafile and mentioned here right after the 35s was introduced a year ago.

35s Review

Datafile, the publication of the HPCC group, is very useful.

www.hpcc.org

And, it also pays to search here on the museum. :-)

                        
Re: 35s: Using STO in EQN in RPN program
Message #5 Posted by Matt Draper on 4 Oct 2008, 10:25 p.m.,
in response to message #4 by Gene Wright

Actually, it was in your review that I first learned about saving intermediate results in an equation. Thanks! It was in the HP manual that I had a hard time finding the relevant information.

I've read so much on the museum this past week that my head is spinning. It's my own fault if I can't absorb it all at once.

I've always loved my 42S, which still runs great after almost 20 years. I resisted buying the 35s for a long time, but your excellent review was a big part of what finally tipped me over the edge and convinced me that it is an interesting machine, and worth a try.

      
Re: 35s: Using STO in EQN in RPN program
Message #6 Posted by V-PN on 4 Oct 2008, 9:16 p.m.,
in response to message #1 by Matt Draper

The only thing I would change is to put the RV before the EQW and then change the register storing accordingly so that 0|>I and REGT (holding X) |>(I) would end the EQW leaving 0 stored in the I register

I could not find anything speeding this up if you deny using RPN

How about a nice recalling program

Also note that storing and restoring always using 0..4 (5) is not helping other applications in saving the stack

I think that the HP 35s, while being a great calculator and fixing most of the 33S deficiencies is still too limited for serious work

We need HP 42s+ with an SD slot one could save surveying data exchange programs etc No, BT, no IR, nor other direct communications might help the acceptance as a school exam calculator

Opinions?

            
Re: 35s: Using STO in EQN in RPN program
Message #7 Posted by Andrew Nikitin on 4 Oct 2008, 9:45 p.m.,
in response to message #6 by V-PN

Quote:
I think that the HP 35s, while being a great calculator and fixing most of the 33S deficiencies is still too limited for serious work

We need HP 42s+ with an SD slot one could save surveying data exchange programs etc No, BT, no IR, nor other direct communications might help the acceptance as a school exam calculator

Opinions?


Absense of interface could be an attempt to save cost. Extra conector could add easily 50%. On a plus side I think it is somewhat sweet that it does not have any other means of entering data other than your fingers. This gives you assurance that whatever is in it you have put there yourself with your own hands and make you ultimately responsible for its content.

It also opens up possibilities for an interesting project -- automated computer controlled key pusher. It could be used to automatically enter long programs and large portions of data, like current ephemeris.

I was considering Lego Mindstorm sets as a platform for such robot. The Mindstorm controller is capable of communicating with comupter. On a mechanical side, Lego pieces are very precisely manufactured from hard and sturdy plastic. It seems to be possible to build them into an open loop robotic finger which will be precise enough to hit the right buttons. They probably would not stand to much abuse, but this seems not to be the problem in this application.

Reading data and programs back would require some kind of usb camera and OCR (combined with robotic finger to push down arrow or to issue a register viewing commands), but I believe it can also fall within hobby budget.

Edited: 4 Oct 2008, 9:46 p.m.

                  
Re: 35s: Using STO in EQN in RPN program
Message #8 Posted by Matt Draper on 4 Oct 2008, 10:47 p.m.,
in response to message #7 by Andrew Nikitin

Quote:
It also opens up possibilities for an interesting project -- automated computer controlled key pusher. It could be used to automatically enter long programs and large portions of data, like current ephemeris.

Every time I copy a long program from one 42S to another, I think about something like this! I'm a machine tool programmer by trade, so I always have a bunch of vertical CNC mills around. I've thought about buying a rubber hand from a trick shop, mounting it to the mill spindle, gently clamping the calculator in a six-inch vise, and programming the hand to press the keys on the calculator. It would look ridiculous, but it'd be great fun.

                        
Re: 35s: Using STO in EQN in RPN program
Message #9 Posted by Andrew Nikitin on 4 Oct 2008, 11:35 p.m.,
in response to message #8 by Matt Draper

My design of a finger is 5 cm portion of a pencil with eraser inserted in a slightly longer tube with a spring from automatic pen and with other end closed. The tube has 2 vertical slits and 2 pins that are inserted in the pesil and protrude from the slits do not let pencil to fall off from open end. When you push on a tube eraser tip gets in contact with a key and as tube keeps moving down spring compresses and eventually overcomes resistance of a key and clicks. This design allows wider allowed vertical range of movement and protects key from excessive force.

Rubber hand sounds way cooler. If you ever do that, please post the video on YouTube.

Edited: 4 Oct 2008, 11:36 p.m.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall