In support of the 33s & 35s
01-02-2018, 03:07 PM
Post: #21
 Michael de Estrada Senior Member Posts: 334 Joined: Dec 2013
RE: In support of the 33s & 35s
(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.
01-02-2018, 03:10 PM
Post: #22
 grsbanks Senior Member Posts: 422 Joined: Jan 2017
RE: In support of the 33s & 35s
(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...
Post: #23
 Michael de Estrada Senior Member Posts: 334 Joined: Dec 2013
RE: In support of the 33s & 35s
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.
01-02-2018, 06:42 PM (This post was last modified: 01-02-2018 06:43 PM by grsbanks.)
Post: #24
 grsbanks Senior Member Posts: 422 Joined: Jan 2017
RE: In support of the 33s & 35s
(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
01-02-2018, 06:53 PM (This post was last modified: 01-02-2018 06:54 PM by pier4r.)
Post: #25
 pier4r Senior Member Posts: 1,562 Joined: Nov 2014
RE: In support of the 33s & 35s
(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.

Wikis are great, Contribute :)
01-03-2018, 05:54 PM
Post: #26
 Michael de Estrada Senior Member Posts: 334 Joined: Dec 2013
RE: In support of the 33s & 35s
(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.
01-03-2018, 07:05 PM (This post was last modified: 01-03-2018 07:05 PM by Dieter.)
Post: #27
 Dieter Senior Member Posts: 2,076 Joined: Dec 2013
RE: In support of the 33s & 35s
(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
01-03-2018, 08:19 PM (This post was last modified: 01-03-2018 08:20 PM by pier4r.)
Post: #28
 pier4r Senior Member Posts: 1,562 Joined: Nov 2014
RE: In support of the 33s & 35s
question. Couldn't 1/3 be replaced by a fixed constant to be just recalled? does it help?

Wikis are great, Contribute :)
01-03-2018, 09:11 PM (This post was last modified: 01-03-2018 09:22 PM by Dieter.)
Post: #29
 Dieter Senior Member Posts: 2,076 Joined: Dec 2013
RE: In support of the 33s & 35s
(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
01-03-2018, 09:34 PM
Post: #30
 Matt Agajanian Senior Member Posts: 404 Joined: Dec 2013
RE: In support of the 33s & 35s
Hi all. This thread seems to have veered away from my original focus. Should I start a new thread?
01-03-2018, 09:43 PM (This post was last modified: 01-03-2018 09:44 PM by Dieter.)
Post: #31
 Dieter Senior Member Posts: 2,076 Joined: Dec 2013
RE: In support of the 33s & 35s
(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?

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
01-03-2018, 10:13 PM (This post was last modified: 01-03-2018 10:13 PM by pier4r.)
Post: #32
 pier4r Senior Member Posts: 1,562 Joined: Nov 2014
RE: In support of the 33s & 35s
(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.

Wikis are great, Contribute :)
01-03-2018, 10:25 PM
Post: #33
 TheKaneB Member Posts: 166 Joined: Jul 2014
RE: In support of the 33s & 35s
well, I have discovered a trick or two to optimize my 35S programs thanks to this "off topic"

Software Failure: Guru Meditation

--
Antonio
IU2KIY
01-03-2018, 10:47 PM
Post: #34
 Trond Member Posts: 78 Joined: Sep 2017
RE: In support of the 33s & 35s
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.
01-03-2018, 10:48 PM
Post: #35
 Matt Agajanian Senior Member Posts: 404 Joined: Dec 2013
RE: In support of the 33s & 35s
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.
01-03-2018, 11:15 PM
Post: #36
 TheKaneB Member Posts: 166 Joined: Jul 2014
RE: In support of the 33s & 35s
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).

Software Failure: Guru Meditation

--
Antonio
IU2KIY
01-03-2018, 11:26 PM
Post: #37
 rprosperi Senior Member Posts: 2,721 Joined: Dec 2013
RE: In support of the 33s & 35s
(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.

--Bob Prosperi
01-03-2018, 11:53 PM
Post: #38
 TheKaneB Member Posts: 166 Joined: Jul 2014
RE: In support of the 33s & 35s
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

Software Failure: Guru Meditation

--
Antonio
IU2KIY
01-04-2018, 07:49 AM (This post was last modified: 01-04-2018 07:56 AM by Dieter.)
Post: #39
 Dieter Senior Member Posts: 2,076 Joined: Dec 2013
RE: In support of the 33s & 35s
(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
01-04-2018, 08:06 AM
Post: #40
 Dieter Senior Member Posts: 2,076 Joined: Dec 2013
RE: In support of the 33s & 35s
(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
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)