The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

16c vs 12c program problem
Message #1 Posted by John Nelson on 20 June 2004, 10:21 a.m.

Ok folks... have a question for you. I have done some programs on my 12c for years now, and find it very easy to use. I recently tried something very simple on my 16c with some unexpected results. I did a very simple program on both to find the % change (I know the 12c can do this out of the box but just humor me for a second).

The program is simple %change = (new - old) / old. The program was as follows. I would store the old value in reg 1, store the new value in reg 2. Then I input the following in P/R mode.

RCL 2 RCL 1 - RCL 1 /

That's it. After the values are stored (say 25 for reg 1 and 45 for reg 2) I run it. On the 12C it kicks back an answer very fast. On the 16C, after a minute it's still running. Why is that? I have the 16C also in Float mode. The correct answer should be 0.80.

Any ideas what I might be doing wrong on the 16c?

      
Re: 16c vs 12c program problem
Message #2 Posted by Veli-Pekka Nousiainen on 20 June 2004, 11:45 a.m.,
in response to message #1 by John Nelson

LBL A
RCL 2
RCL 1
[ - ]
RCL 1
[ / ]
[R/S]
GTO A
(say 25 for reg 1 and 45 for reg 2)

The answer is .80
Double check your program - is the 26C broken???
[VPN]

            
Re: 16c vs 12c program problem
Message #3 Posted by John Nelson on 20 June 2004, 1:37 p.m.,
in response to message #2 by Veli-Pekka Nousiainen

Ok.... well that works. Why did I have to label it and do a goto and include the R/S in it? On the 12C I don't have to do any of that. Any ideas as to why?

                  
Re: 16c vs 12c program problem
Message #4 Posted by Don Shepherd on 20 June 2004, 2:26 p.m.,
in response to message #3 by John Nelson

John, the program should work as you entered it, you don't need the label and goto. I ran it on my 16c and it worked fine. Did you "Clear Program" prior to entering the program? If not, and you had another program already loaded, that may be your problem.

                        
Re: 16c vs 12c program problem
Message #5 Posted by John Nelson on 20 June 2004, 2:50 p.m.,
in response to message #4 by Don Shepherd

Yes... did a clear program by pressing the f and the PRGM key.

It something though, when I ran it with Veli-Pekka's version it worked fine. Only note is it took about 5 seconds to tun where as on the 12C it took only 1-2 seconds. Not sure why.

                              
Re: 16c vs 12c program problem
Message #6 Posted by Don Shepherd on 20 June 2004, 3:38 p.m.,
in response to message #5 by John Nelson

John, the 12c runs faster because it is "newer" and undoubtedly has a faster processor than the 16c, which hasn't been made since the mid-80's I believe. For the same reason, the 12c Platinum's run faster than older 12c's.

                              
Re: 16c vs 12c program problem
Message #7 Posted by Veli-Pekka Nousiainen on 20 June 2004, 5:41 p.m.,
in response to message #5 by John Nelson

Something is wrong here...
I can't measure the running time in either HP-12C or 16C
They are both too fast.
Nowhere near a second
{VPN}

                              
Re: 16c vs 12c program problem
Message #8 Posted by John Nelson on 21 June 2004, 11:03 a.m.,
in response to message #5 by John Nelson

Strange... I did a clear on the program when not in the program listing and it loops it seems. But now I just did an clear when in the program listing and entered the program again. Now it works.

Not sure what that was all about....

                                    
Re: 16c vs 12c program problem (edited for erors)
Message #9 Posted by Vieira, Luiz C. (Brazil) on 21 June 2004, 2:59 p.m.,
in response to message #8 by John Nelson

Hi, John;

the sequence [f]CLEAR[PRGM] in all voyagers only clears program memory when the calculator is in PRGM (program) mode. If the calculator is in normal (RUN) mode (no PRGM indicator), it simply positions the program "pointer" at program top, i.e., step 00- (or 000-, if you are using an HP11C, 15C or 16C).

Keep in mind that this is not valid if you have an HP12C Platinum. According to Jordi Hidalgo's important mention in one of his papers, the HP12C Platinum has no "return to 000-" feature after [f]CLEAR[PRGM] keystroke is used while the calculator is in normal (RUN) mode.

So, your observations AND calculator behavior are correct.

Cheers.

Luiz (Brzil)

Edited: 21 June 2004, 4:42 p.m.

                  
Re: 16c vs 12c program problem
Message #10 Posted by Vieira, Luiz C. (Brazil) on 20 June 2004, 3:34 p.m.,
in response to message #3 by John Nelson

Hi, John;

I agree with Don about both: the no need for adding the LBL and GTO (or RTN), that would actualy "separate" your program from others in memory, and I also agree with him about the possibility of existing programs in memory so your

RCL 2
RCL 1
-
RCL 1
÷
is, in fact, running correctly and right after obtainning the answer, it goes for another program that may be the one that is running in loop.

About the HP12C program structure. As you seem to be a 12C user, you know that everytime you type in an additional function at the end of a program that claims an extra, nonavailable byte, all remaining six bytes of the "converted" register are filled with

43,33 00
or [g][GTO]00. This does not happen in the HP16C: even if extra bytes are claimed to compose program steps, they are only used when additional functions actualy claim these bytes. In other words, you don't "see" them unless you "use" them. Based on the HP16C structure, you'll never have such [GTO]program_step because the 16C knows only [GTO]label, while the HP12C (and the HP10C as well) only knows [GTO]program_step.

In your example, the sequence

RCL 2
RCL 1
-
RCL 1
÷
uses 5 bytes and if it is the only program in memory, three
43,33 00
will still be available, and when any of them is executed in a running program, the calculator will be positioned in step 00- and the program stops. that's probably the reason that the program runs correctly in the HP12C.

The other additional feature in the HP16C is that new functions (program steps) "pull" all existing program steps "up" when they are added, and none of the existing steps is deleted. In the HP12C, each new program step replaces an exisitng one. It's like the HP16C program mode is always in "isertion" mode, while the HP12C program mode is always in "replace" mode.

Hope this helps.

Luiz (Brazil)

Edited: 20 June 2004, 3:36 p.m.

                  
Re: 16c vs 12c program problem
Message #11 Posted by Cameron on 20 June 2004, 9:34 p.m.,
in response to message #3 by John Nelson

VPN set his steps up so you could use it repeatedly, as in:

new-value STO 2
old-value STO 1
R/S

Every time you press R/S, it computes the new % change and stops, waiting for you to change values and press R/S again.

You could achieve much the same thing by changing the R/S in the program to RTN (43 21). Then you would run it by:

new-value STO 2
old-value STO 1
GSB A

This has a small additional advantage that will only be realised if you have more than one program loaded. VPN's version is "better" because it saves you a keystroke when using it repeatedly.

As for 5-second execution time, there is something NQR there. I time it between 0.75 and 1.25 seconds. For reasons that I cannot explain (but that I have speculated about for a long time) the 16C is the slowest Voyager by a *significant* amount. It scores a meagre 3.558 on David's MoHPC math benchmark. As a comparison, the 11C scores 6 (David didn't test the 12C and I don't have one but you could do the test yourself).

Cameron

      
delta-% on the 16C
Message #12 Posted by Karl Schneider on 21 June 2004, 3:28 a.m.,
in response to message #1 by John Nelson

John --

The delta-% program on HP RPN calc's has some sophistication built in. The "original" value, which must be in the Y stack register, is retained there after delta-% is executed. The "new" value, which must be in the X stack register, is recoverable with "Last x" after execution.

Also, delta-% using an original value of 0 will return an "Error 0" or comparable message.

The typical usage is 

"orig value" 
ENTER 
"new value"
delta-%

Here's a 16C program that functions like the one on the 11C/12C/15C/34C, et al., with the following exceptions:

  • X, Y, and Z stack registers are used, instead of just X and Y.
  • "Last x" does not recover "new" value.
  • Clearing DBZ error leaves "orig" and "new" values swapped. 

LBL "A"     43,22,A  (I wish the 15C coded as such!)
x<->y       34
x=0?        43 40
/           10       Induces DBZ error for "orig" value = 0 
-           30       x-y  [based on originally-entered values]
LST x       43 36    y
/           10       (x-y)/y
LST x       43 36    y
x<->y       34
EEX         42 49
2            2
*           20       [(x-y)/y] * 100% (as shown on back of 15C)
RTN         43 21

-- Karl S.

Edited: 21 June 2004, 10:52 p.m.

      
Re: 16c vs 12c program problem
Message #13 Posted by Gordon Dyer on 21 June 2004, 6:42 p.m.,
in response to message #1 by John Nelson

I have tried this on my 11C, 12C and 16C and they all work out 0.8.
The 16C is the slowest.

            
Karl's program exposed a bug in my sim
Message #14 Posted by Cameron on 21 June 2004, 9:06 p.m.,
in response to message #13 by Gordon Dyer

Don't try it on the sim (yet). Karl's program exposed a subtle difference between the simulator and the real calculator. EEX has an implicit mantissa of 1. I wasn't simulating that because I've never thought to try it.

Version 0.318 corrects this. I have it on my test bench today. I'll probably release it this weekend.

Cameron

[ Return to Index | Top of Index ]

Go back to the main exhibit hall