In support of the 33s & 35s
|
01-02-2018, 03:07 PM
Post: #21
|
|||
|
|||
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>. 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
|
|||
|
|||
RE: In support of the 33s & 35s | |||
01-02-2018, 05:13 PM
(This post was last modified: 01-02-2018 05:14 PM by Michael de Estrada.)
Post: #23
|
|||
|
|||
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
|
|||
|
|||
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 |
|||
01-02-2018, 06:53 PM
(This post was last modified: 01-02-2018 06:54 PM by pier4r.)
Post: #25
|
|||
|
|||
RE: In support of the 33s & 35s
(01-02-2018 05:13 PM)Michael de Estrada Wrote: And another: 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
|
|||
|
|||
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 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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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? 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 |
|||
01-03-2018, 10:13 PM
(This post was last modified: 01-03-2018 10:13 PM by pier4r.)
Post: #32
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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:
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
|
|||
|
|||
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: ... 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
|
|||
|
|||
RE: In support of the 33s & 35s | |||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)