RPN versus ALG in programs

[Thomas Klemm]

Just recently I stumbled across Katie Wasserman's fine article
99 Digits of PI on an HP 32SII
which I apreciated a lot. It made me have a look again at the different algorithms to calculate
Pi. After implementing a RPN-version of the Gauss AGM algorithm for the 35s I was curious on
how to do the ALG-version. Here's the result of both:

RPN                            ALG

G001 LBL G                     H001 LBL H

G002 1                         H002 1>A

G003 STO A                     H003 3>I

G004 3                         H004 SQRT(0.5>P>S)>B

G005 STO I                     H005 S-SQ(A-B)*P>S

G006 0.5                       H006 2*P>P

G007 STO P                     H007 (A+B)/2

G008 STO S                     H008 SQRT(A*B)>B

G009 SQRT                      H009 REGY>A

G010 STO B                     H010 DSE I

G011 RCL- A                    H011 GTO H005

G012 x2                        H012 SQ(A+B)/(2*S)

G013 RCL* P                    H013 RTN

G014 STO- S

G015 RCL A                     LN=115

G016 RCL+ B

G017 2

G018 STO* P

G019 /

G020 x<> A

G021 RCL* B

G022 SQRT

G023 STO B

G024 DSE I

G025 GTO G011

G026 RCL+ A

G027 x2

G028 RCL/ S

G029 2

G030 /

G031 RTN

LN=100

(inspired by algorithm 7.5 from Arndt & Haenel, Pi-unleashed)

Now if you run both variants you will find that H is about 4 times slower than G.
Also H seems to use more memory than G. On the other hand H might be easier to
read. But you have to scroll to be able to read the whole lines.

What I don't understand is why is H so slow? I mean both are kind of slow but H
is realy bad. Hey, there are only 3 iterations and it takes about 4 seconds!

Being curious about the performance I implemented the same algorithm for my 11c as well:

01 LBL A                 21 SQRT

02 3                     22 x<>y

03 STO I                 23 R^

04 2                     24 x2

05 1/x                   25 RCL 1

06 STO 0                 26 *

07 STO 1                 27 STO- 0

08 SQRT                  28 RDN

09 ENTER                 29 2

10 ENTER                 30 STO* 1

11 ENTER                 31 /

12 1                     32 DSE

13 LBL 0                 33 GTO 0

14 -                     34 +

15 R^                    35 x2

16 LSTx                  36 RCL 0

17 +                     37 /

18 R^                    38 2

19 LSTx                  39 /

20 *                     40 RTN

Not to my surprise it's considerably slower taking about twice the time of H.
But when I ran the same program on a 42s I was amazed: Though it's slower than G
it beats H by far.

Twenty years later and not much improvement concerning the speed! Does anybody
know why? Is it so difficult to construct a fast calculator?

I must admit that I'm quiet happy with the 35s in spite of the issues already
mentioned in this forum. But I'd really like to have a calculator that is fast,
e.g. counts to a million in less than a second.

In other interpreted languages it's possible:

> time perl -e 'for ($i=0; $i<1e6; $i++) {}'

real    0m0.219s

user    0m0.199s

sys     0m0.003s

So why can't we have that in a calculator as well?

Thomas

[Jeff Kearns]

Agreed. Calculators are still too slow for many 'routine' operations considering the fact that we are in 2007. I tried your interesting 11C program out on my 15C and have the following comment regarding step 32.

Quote:

---

Being curious about the performance I implemented the same algorithm for my 11c as well:

01 LBL A                 21 SQRT

02 3                     22 x<>y

03 STO I                 23 R^

04 2                     24 x2

05 1/x                   25 RCL 1

06 STO 0                 26 *

07 STO 1                 27 STO- 0

08 SQRT                  28 RDN

09 ENTER                 29 2

10 ENTER                 30 STO* 1

11 ENTER                 31 /

12 1                     32 DSE

13 LBL 0                 33 GTO 0

14 -                     34 +

15 R^                    35 x2

16 LSTx                  36 RCL 0

17 +                     37 /

18 R^                    38 2

19 LSTx                  39 /

20 *                     40 RTN

---

Step 32, above should read

032 - 42, 5,25 DSE I - at least in order to work on my 15C. Regards,

JeffK
I

[Dave Shaffer (Arizona)]

Speed costs you in power.

Every time one of those CMOS gates changes state, a bit of your battery charge disappears. I guess you could have a faster machine, but you might have to change the battery more often than you'd appreciate. All those 11Cs and 15Cs that lasted for 15-20 years on the same battery weren't just dumb luck!

[DaveJ]

Quote:

---

Twenty years later and not much improvement concerning the speed! Does anybody
know why? Is it so difficult to construct a fast calculator?

---

Power consumption is roughly proportional to processing speed, the tradeoff has to be made somewhere.
And on top of that, the 35S is no doubt written in C, probably with a deal of thought toward code portability and re-use (that usually means bigger code), so that costs you in performance in two ways alone. Whereas the older machines were most likely hand coded in assembler and hence gave better bang-per-bucks on each clock cycle.

Dave.

[Vieira, Luiz C. (Brazil)]

Hi, Thomas;

(here I am at 4:50 AM feeling insomnia...)

many of us who not only use and deal with HP calculators but also try to go further to their 'guts' have probably read that RPN structures were achieved mostly in search of a resident 'proto', portable operating system that could fit in less ROM, OR could offer the most in the same available ROM space. So, RPN offers many intersting features BUT math precedence. I like to say that math precedence in RPN calculators must be provided by the user, who must master math prior to use an RPN calculator. That is why I think RPN is educative, but I'd rather not going ahead with that in order to avoid seeting fire in extinguished fireplaces...

To achieve algebric operation, it is mandatory to have at least a few registers to store the first keyed-in number and the code of the operation to be performed (for two-number sequences) so you can key in the second value and press [=] key. Keep in mind that there is no way to count on system 'memory' to hold necessary data if this memory has not yet been provided, meaning that, in any digital device, data must reside somewhere, and this 'somewhere' needs a very well defined address and physical circuits... Sorry if you already know about this.

RPN calculators demand no structure for precedence operators because whenever the operation key is pressed, the number(s) over which such operations will be performed must exist in the stack (in programs it happens the same). So they are already stored in X and Y registers and the system only needs to retrieve a copy of them and go ahead with the operations.

Consider line H008 SQRT(A*B)>B in your listing. You see, prior to get the resulting value from SQRT(A*B), the system must store the codes for:

SQRT( (a code for calling it, not the routine itself)

A

*

B  (in RPN/ALG HP calculators, shares X-register address)

A total of four registers taken from somewhere in RAM, meaning that it actually uses more memory as you noticed, indeed. When the ')' is found, the whole sequence is 'unloaded' and the result is found.

The system uses some cycles (clock) to store the intermediate codes, some others to 'unload' them and the actually necessary cycles to perform then. It may take almost three to four times more time when compared to the RPN version.

I may have left some considerations behind, but I guess the most important facts are described here already.

Hope this helps.

My 2¢.

Luiz (Brazil)

Edited: 27 Aug 2007, 4:39 a.m.