In support of the 33s & 35s

[Michael de Estrada]

(01-02-2018 10:25 AM)pier4r Wrote:  

(01-02-2018 12:58 AM)Michael de Estrada Wrote:  I ran this code on my HP 35s, and the execution time for N=1000 has increased from the reported 287 seconds to 309 seconds. The code is the same, except the HP 35s lacks a dedicated cube root of x function key, so I needed to replace it with 3 <x root of y>.

Anyway for the 35s I guess grsbanks (if I remember who reported the timings) used another algorithm to be slightly faster. Could it be?

No doubt the results will vary depending on the coding efficiency, as there are many different choices that can be made. For example, I created the loop by incrementing a counter and using a value test for branch control, but I also could have automated it using the built-in loop control functions DSE ISG, which may have reduced execution times.

[grsbanks]

(01-02-2018 10:25 AM)pier4r Wrote:  Anyway for the 35s I guess grsbanks (if I remmeber who reported the timings) used another algorithm to be slightly faster. Could it be?

I'll post the program I used when I get home. I think it's still in the calculator's memory...

[Michael de Estrada]

And another:

HP-34C (Spice): N=10, 46 seconds, Result=13.71183501

What I find interesting is that the Spice is slower than the HP-29C Woodstock (35 seconds), despite being a newer generation calculator.

[grsbanks]

(01-02-2018 10:25 AM)pier4r Wrote:  Anyway for the 35s I guess grsbanks (if I remember who reported the timings) used another algorithm to be slightly faster. Could it be?

I just ran the test agan and got 286 seconds this time, so I can confirm that my initial report of 287s was "correct".

This is the program I used. Note that everything is accumulated in the stack to speed things up and I do use a DSE instruction to avoid having to do the end-of-loop test the "old fashioned" way. The 35S is slow enough as it is so let's give it a fighting chance

Code:

S001 LBL S
S002 RAD
S003 ABS
S004 IP
S005 STO I
S006 CLSTK
S007 RCL I
S008 ATAN
S009 SIN
S010 E^X
S011 3
S012 1/X
SO13 Y^X
S014 +
S015 DSE I
S016 GTO S007
S017 STOP
S018 GTO S003

[pier4r]

(01-02-2018 05:13 PM)Michael de Estrada Wrote:  And another:

HP-34C (Spice): N=10, 46 seconds, Result=13.71183501

What I find interesting is that the Spice is slower than the HP-29C Woodstock (35 seconds), despite being a newer generation calculator.

Holy moly this is slow! (ok, it is also a very old calculator)

With my sharp 506w using 3 variables I needed 47 seconds (yes me, typing the different values of X), without that much of time stress to be "fast".

This let me appreciate the old calculators even more. All those people that couldn't use computers, for example due to lack of proper scientific functions or budget, they may had to wait long time for answers to some math simulations.

[Michael de Estrada]

(01-02-2018 06:42 PM)grsbanks Wrote:  

(01-02-2018 10:25 AM)pier4r Wrote:  Anyway for the 35s I guess grsbanks (if I remember who reported the timings) used another algorithm to be slightly faster. Could it be?

I just ran the test agan and got 286 seconds this time, so I can confirm that my initial report of 287s was "correct".

This is the program I used. Note that everything is accumulated in the stack to speed things up and I do use a DSE instruction to avoid having to do the end-of-loop test the "old fashioned" way. The 35S is slow enough as it is so let's give it a fighting chance

Code:

S001 LBL S
S002 RAD
S003 ABS
S004 IP
S005 STO I
S006 CLSTK
S007 RCL I
S008 ATAN
S009 SIN
S010 E^X
S011 3
S012 1/X
SO13 Y^X
S014 +
S015 DSE I
S016 GTO S007
S017 STOP
S018 GTO S003

I ran your code on my HP 33s and was surprised that my execution times actually increased. It was still faster than the HP 35s, but the differences were not as large. So just because a code is more efficient for one calculator does not mean it will be so for another.

As a side note, you could have reduced the run times slightly on the HP 35s by replacing the sequence 3 1/X Y^X with 3 <X root of Y>. Using this code on both the HP 33s and HP 35s with N=1000 yields a run time of 282 sec on the HP 35s and 217 sec on the HP 33s.

The only part of your code that I could not enter directly was CLSTK, which I replaced with CLx ENTER ENTER ENTER. This should have a negligible effect on execution time, since it falls outside the summation loop.

[Dieter]

(01-03-2018 05:54 PM)Michael de Estrada Wrote:  As a side note, you could have reduced the run times slightly on the HP 35s by replacing the sequence 3 1/X Y^X with 3 <X root of Y>.

And that's even more accurate.

You may also squeeze out a few more seconds if you replace the "3" with a variable (e.g. RCL T) which is initialized in the first steps. Numeric constants are quite slow on the 35s, for me it looks like they are handled as equations.

(01-03-2018 05:54 PM)Michael de Estrada Wrote:  The only part of your code that I could not enter directly was CLSTK, which I replaced with CLx ENTER ENTER ENTER.

And the 33s has no line addressing, so you'll need another label. This again means that one single ENTER will do here. ;-)
BTW, line addressing is great – I really love it on the 35s.

Dieter

[pier4r]

question. Couldn't 1/3 be replaced by a fixed constant to be just recalled? does it help?

[Dieter]

(01-03-2018 08:19 PM)pier4r Wrote:  question. Couldn't 1/3 be replaced by a fixed constant to be just recalled? does it help?

Most probably: yes. But I guess that 3 XROOT (with a recalled, prestored 3) is even faster.
And of course more accurate: x^0,333333333333 is not the same as x^(1/3).

Edit: results for HP35s in RAD mode, using RCL T XROOT

n=100: 27,5 s
n=1000: 253 s

:-D

Dieter

[Matt Agajanian]

Hi all. This thread seems to have veered away from my original focus. Should I start a new thread?

[Dieter]

(01-03-2018 09:34 PM)Matt Agajanian Wrote:  Hi all. This thread seems to have veered away from my original focus.

Such is life on the internet. Remember the golden era of usenet ?-)

(01-03-2018 09:34 PM)Matt Agajanian Wrote:  Should I start a new thread?

No, why? That other thread on calculator speed already exists. ;-)

But IMHO we're completely on topic here: we are discussing ways of getting the most out of the 35s, and I think this matches the intention of the original post very well.

Dieter

[pier4r]

(01-03-2018 09:34 PM)Matt Agajanian Wrote:  Hi all. This thread seems to have veered away from my original focus. Should I start a new thread?

I don't think you would get further replies. Normally "side" discussions help to fuel the discussion in the main topic that otherwise can be considered as inactive. Furthermore people are providing points to compare the 33s vs 35s so I find it still valid.

[TheKaneB]

well, I have discovered a trick or two to optimize my 35S programs thanks to this "off topic"

[Trond]

For the record, I think HP 35S is great. There are a couple of flaws (like any piece of electronics), but they have not impacted my use of the calculator much, and some of the good things (e.g. good screen, and navigating around with the arrow keys) are really awesome and user friendly.

[Matt Agajanian]

Thanks, Dieter and Pier4r for explaining how these previous posts ADD to the functionality, usefulness, and computing potential of the 33s & 35s.

I’m glad you pointed these out because they strengthen the cases for the 33s and 35s.

[TheKaneB]

I tried my own version of this algorithm and I did over 6 minutes in radians mode (>360 seconds!) using DSE and I stored 3 in the T register and did the cube root as RCL T XROOT. I don't know what's wrong with my code, but might be that the STO+ function is slower than the regular + on the stack (plus other factors).

[rprosperi]

(01-03-2018 11:15 PM)TheKaneB Wrote:  I tried my own version of this algorithm and I did over 6 minutes in radians mode (>360 seconds!) using DSE and I stored 3 in the T register and did the cube root as RCL T XROOT. I don't know what's wrong with my code, but might be that the STO+ function is slower than the regular + on the stack (plus other factors).

It's hard to say for sure without seeing all your code, but I'd guess that you are pushing your 3, initially in the T register, off the top of the stack; for example the RCL T raises the stack, pushing the T off; if that's in your loop, you'll be in trouble quickly.

[TheKaneB]

Nevermind, my code had a few bugs in it, so the test was invalid.

With correct code now I have 4m 15s or 255 seconds, which is perfectly fine according to previous tests (my code actually is just a variations of those you guys posted before).

Here is my code:

Code:


B001 LBL B
B002 INPUT N
B003 0
B004 STO S
B005 3
B006 STO T
C001 LBL C
C002 RCL N
C003 ATAN
C004 SIN
C005 e^x
C006 RCL T
C007 x-root-of-y
C008 STO+ S
C009 DSE N
C010 GTO C001
C011 RCL S
C012 RTN

With N=1000, Radians mode, the output is displayed as 1395.34628766

[Dieter]

(01-03-2018 11:26 PM)rprosperi Wrote:  It's hard to say for sure without seeing all your code, but I'd guess that you are pushing your 3, initially in the T register, off the top of the stack; for example the RCL T raises the stack, pushing the T off; if that's in your loop, you'll be in trouble quickly.

Perhaps I should have suggested a different variable name than "T" (as in "three") to avoid confusion: The stack's T-register is not affected here, every "T" refers to a variable T that holds the constant "3" which has been initially stored there.

Code:

...
3
STO T
...
RCL T
XROOT
...

BTW, the real 35s nerd of course replaces the 3 with pi IP which consumes less memory and probably is even faster. ;-)

Dieter

[Dieter]

(01-03-2018 11:53 PM)TheKaneB Wrote:  Here is my code:

LBL C is not required, the 35s can branch to any program line. So remove LBL C and GTO B007 instead. This way the loop also is one step shorter.

Dieter