33s: parentheses within program


I am new to the 33s - just got it yesterday so I will be comfortable with it by the time my FE exam rolls around next year. I imagine it would be handy to be able to do both linear systems and vector math on the FE, so I set right in to keying in the routines given in the manual. Besides having to change some conflicting labels between the two routines, it went well - until the dot product loop. The program doesn't work and the checksum is wrong. I double checked everything and it looks right, so I stepped through. It gives me an "Invalid equation" error on lines D0021 and D0026 - the two parentheses. Here's what it looks like in the book:

D0018 RCL W
D0019 y,x -> Q,r [yes, that's a theta]
D0020 STO E
D0021 (
D0022 RCL D
D0023 RCL/ R [that's a division sign :- with the line slid left]
D0024 / [again, the division sign]
D0025 RCL E
D0026 )
D0027 ACOS
The only way I could find to get the parentheses to appear was to enter them with purplearrow-EQN purplearrow-( That makes the eqn annunciator come up whenever I scroll past those two lines. Perhaps that is not the right way to enter parens? I tried just purplearrow-( but that didn't do anything.

Any suggestions?



would that be possible to scan the book's listing and allow us to have a look at it?

I do not use the HP33S in Algebraic mode, and I do not have mine in hands right now, so I cannot tell about how does it handle parenthesis in RPN mode.

So, my suggestion is: should you try algebraic mode? At least I am considering the fact that you are using it in RPN mode, the default one.

Best regards.

Luiz (Brazil)


for those of us with the manual a page number is good too.


should you try algebraic mode?

Ah. Now that you ask I see that that is written at the top of the page. That seems to fix it - mostly. Now I get the same results as the sample routines given in the book. My checksum is still off, though. Hopefully that is a mistake in the given checksum?

I don't have a scanner, but this section of the program in question is on page 15-6 of the manual, which can be found online athttp://h10032.www1.hp.com/ctg/Manual/c00059731.pdf
If someone else could key in D0001-D0030 and confirm the checksum, that would be great.

Thanks for the help, everyone - This is a fun calculator - I know it can't do as much as my 48gx, but since I have the manual for this one, I am already learning to use a much higher portion of its capabilities. (to me, the 48g is like a black box, so to speak)


If you had to relabel things to avoid label duplication, the checksum would change, since the program isn't an exact duplicate of the listing that generated the original checksum.


Relabeling - I relabeled everything in the linearsystem routine, once I got it working, then typed in this one exactly as it reads in the book.

Thanks for the link on the other!



Edited: 24 Feb 2007, 10:09 a.m.


Now I get the same results as the sample routines given in the book. My checksum is still off, though. Hopefully that is a mistake in the given checksum?
I retract that claim. I thought it was working, but it wasn't. To get it to work, I had to go back into the program and re-enter the parentheses lines while in ALG mode - which was much easier than it was in rpn mode. I assume that my other entry technique must have left some invisible whitespace or something that was causing problems.

Now it is /really/ working. Just wish I didn't have to switch to ALG mode to use it.

Thanks again, everyone,




I definetely echo your frustrations with the lack of matrix support on the 33s.

I have successfully used the Gauss-Seidel method on my 33s. It is a numeric-iterative approach to solving linear systems. Using it does, however, require you to consider a few characteristics about the system that you wish to solve [you have to think :)]

You must consider the dominant diagonal, the initial value (usually try setting all to zero), among a few others. Don't try to "get it" the first time you read this post, just read through it, and then re-read it (perhaps after googling Gauss-Seidel).

Now, here is one insight...on systems that are appropriate (ie. diagonally dominant, etc) in other words, academic problems that are designed to be solved, you can usually expect a convergence on the correct solution vector.

Anyway, the approach is essentially like this:

1. Take a system, say 4 variables, and algebraically solve each one for one of the variables. So, you solve the first equation for X, the second one for Y, etc.

2. Now, key these in as a 33s keystroke program.

Actually, let me just give a pseudo-code to illustrate it:

say we have the following:

Ax + By + Cz = D

Ex + Fy + Gz = H

Ix + Jy + Kz = L

here's the pseudocode:

1. store your coefficients


2. Solve the first eqn for X:

RCL D, RCL Z, RCL *C, -, RCL B, RCL *y, -, RCL /A, STO X

3. Solve the second eqn for Y:

RCL H, RCL Z, RCL *G, -, RCL E, RCL *X, -, RCL/F, STO Y (Note that this equation uses the approximation for X that you just obtained previously...likewise, Step 4 will use both that X and also the Y that you are currently solving)

4. Solve the third eqn for Z, following the above approach.

So the idea is that each subsequent equation in the system gets the most current approximation. If you enter a good system, you can expect convergence. This may at times mean reordering your system (like Gauss-Jordan with pivoting). This essentially means that you flip columns and rows (before entering the coefficients) so that you have a diagonally-dominant system.

At this point you want to consider looping through this again, since you will get closer to the actual answer each time you iterate. How to decide when you are happy with the result? Well, consider putting in a check, like compare the new X with the previous X, and set a tolerance like Xo - X < 0.01. This will let the calculator terminate the loop when it begins to split hairs.

As you may realize, there's remains some coding on your part for this to run on your 33s. If it had the USB support like the 50g I'd have posted a link for you. But I'm not up to typing in the whole routine (plus I assume you'd have more fun figuring it out).

The nice thing is that I believe I can run this using at MOST two labels (meaning you don't eat up the volume of registers as the HP code listing does). This leaves more labels for you to store other stuff. You can do this for as large a system as you can squeeze variables. There are tricks like freeing up variables once you've used them to permit a larger system, or even having the code prompt the user for stack entries on the fly to let you run a huge system.

This is why I love machines like the 33s...they really force you to get creative! But, alas as engineers we need problems solved, and must often resort to computers for things like finite element methods. Still, its never a crime to stretch your brains as a student (when many problems are solvable with limited resources) or simply to "pull it off".

Have fun. (To all the detractors of my earlier post regarding the 42s, hope this message warms your hearts and makes you happy that I'm a contributor)


PS. I'll now "HAVE" to type my afforementioned code out and submit it to D.H. so it can join the program listings on this site.


One of the "quirks" (well, actually it is not a quirk, it is more a consistency thing) on the 33s is that ALG features (such as the parenthesis) only function while in ALG mode (of course they also function in equation mode even if RPN is active).

When editing programs, you do need to be aware of what mode you are in while editing. Of course you also need the machine to be in the appropriate mode before running the program.

Note that setting the mode is a *programmable* function, and so you can design programs that first set the mode, and then operate in that mode. But you still have to be 'manually aware' of your mode setting while you are 'manually' editing a program.




Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime: run a program in another program Davi Ribeiro de Oliveira 6 1,673 11-11-2013, 08:28 PM
Last Post: Davi Ribeiro de Oliveira
  Maximum number of program steps in HP-42S, 33S, and 35S? Walter B 3 1,121 12-18-2012, 03:44 PM
Last Post: Eric Smith
  Program Coding Sheets for 33s/35s Matt Agajanian 6 1,563 03-03-2012, 04:03 PM
Last Post: David Hayden
  HP-41 MCODE: Making an MCODE program call another MCODE program Geir Isene 10 1,984 01-13-2008, 05:58 AM
Last Post: Raymond Del Tondo
  HP 33s: Addressing registers at the "Top" of the program list. Ted Madson 0 466 10-23-2007, 05:11 PM
Last Post: Ted Madson
  Program format from 33s to 35s romeo_charlie 10 1,937 09-16-2007, 05:02 PM
Last Post: Paul Dale
  HP35s's Parentheses Walter B 10 1,848 07-11-2007, 11:14 AM
Last Post: Dave Johnson
  Program Loss in HP-33S Ed Look 3 904 04-09-2007, 10:21 PM
Last Post: Ed Look
  Integration Times "Old" 33s vs "New" 33s John Smitherman 21 3,487 12-14-2005, 12:04 AM
Last Post: Karl Schneider
  lcm program on hp 33s kevin 4 948 12-12-2005, 11:12 AM
Last Post: Valentin Albillo

Forum Jump: