Programming Exercise (HP-15C, 15C LE - and others)
03-29-2014, 08:51 PM
Post: #61
 Thomas Klemm Senior Member Posts: 1,616 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-29-2014 08:07 PM)Tugdual Wrote:  Hmmm kinda depend on the version you have now
Could it be from 2013-08? IIRC it was the first official release. Though I only seldom read Prime-related threads I realized that there was a recent bugfix-release. But I don't know whether the emulator was updated as well.
It wasn't possible to copy the release-information as text. Thus I didn't include it in my previous post. And right now I don't have access to the emulator anymore.
But don't worry: the question is barely worth the effort.

Kind regards
Thomas
03-29-2014, 09:19 PM
Post: #62
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-29-2014 08:51 PM)Thomas Klemm Wrote:
(03-29-2014 08:07 PM)Tugdual Wrote:  Hmmm kinda depend on the version you have now
Could it be from 2013-08? IIRC it was the first official release. Though I only seldom read Prime-related threads I realized that there was a recent bugfix-release. But I don't know whether the emulator was updated as well.
It wasn't possible to copy the release-information as text. Thus I didn't include it in my previous post. And right now I don't have access to the emulator anymore.
But don't worry: the question is barely worth the effort.

Kind regards
Thomas
In order to update (or check version) you may simply start the connection Kit and then in the help menu there is an option to check the latest version.
03-30-2014, 12:07 AM
Post: #63
 Gerson W. Barbosa Senior Member Posts: 1,454 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-28-2014 03:18 AM)bkn42 Wrote:  I implemented the two term version of this on my "HP55".
Here is the code (sorry its not in location/keycode form but you get the idea):
Code:
   1 -   STO 0   0   STO 1 08:  X<>Y   ENTER   ENTER   *   +   1/x   STO + 1   2   STO - 0   RCL 0   0   X<=Y 0 8   RCL 1   GTO 0 0
R0 holds the current iteration and R1 is the series sum.

For N=100, it took about 82sec to finish. Based on this it would take about 2.25hours for N=10000.

The following is a direct conversion of the HP-15C program to calculate pi in the beginning of this thread, so it's rather long: 49 steps, all the programming memory space of the HP-55!

Code:
 01 ENTER 02 STO   03 0 04 STO 05 +  06 0 07 4 08 STO  09 1 10 * 11 1/x 12 + 13 1/x 14 STO  15 2 16 CLx 17 ENTER 18 ENTER 19 Rv 20 Rv 21 1 22 STO 23 - 24 0 25 Rv 26 RCL 27 1 28 CHS 29 STO  30 1 31 RCL  32 0 33 / 34 + 35 1 36 STO 37 -  38 0 39 Rv 40 RCL 41 0 42 2  43 f 44 x<=y 19 45 Rv 46 Rv 47 RCL 48 2 49 +

66 R/S --> 3.141592654 (2 m 37 s)
03-30-2014, 12:51 AM
Post: #64
 Marcel Samek Member Posts: 53 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote:  66 R/S --> 3.141592654 (2 m 37 s)

I took your program and put it on the HP-67. Same result in 1 m 16 s. The other HP-55 program when run on the hp-67 had run a little less than twice as fast, while this ran a little more than twice as fast. With the exception of the label for the goto, the programs are identical.

I assume that the difference is that this program is longer and the penalty for the non-merged instructions is making the difference.
03-30-2014, 01:38 AM (This post was last modified: 03-30-2014 01:39 AM by Gerson W. Barbosa.)
Post: #65
 Gerson W. Barbosa Senior Member Posts: 1,454 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-30-2014 12:51 AM)Marcel Samek Wrote:
(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote:  66 R/S --> 3.141592654 (2 m 37 s)

I took your program and put it on the HP-67. Same result in 1 m 16 s. The other HP-55 program when run on the hp-67 had run a little less than twice as fast, while this ran a little more than twice as fast. With the exception of the label for the goto, the programs are identical.

I assume that the difference is that this program is longer and the penalty for the non-merged instructions is making the difference.
I'd better have used another register for summing up the terms rather than the stack. This would save at least two steps inside the loop. No more than some ten second gain, I think (unless some optimization is tried - no idea about though). Even the prefix key takes up one step. This makes 49 steps almost nothing!
03-30-2014, 03:12 AM
Post: #66
 bkn42 Junior Member Posts: 20 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote:  66 R/S --> 3.141592654 (2 m 37 s)

My FPGA "HP-55" gets the same answer but in under 1/2 second in turbo mode.

Brian
03-30-2014, 03:51 AM (This post was last modified: 03-30-2014 04:20 AM by Gerson W. Barbosa.)
Post: #67
 Gerson W. Barbosa Senior Member Posts: 1,454 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-30-2014 03:12 AM)bkn42 Wrote:
(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote:  66 R/S --> 3.141592654 (2 m 37 s)

My FPGA "HP-55" gets the same answer but in under 1/2 second in turbo mode.

Brian

Thank you for bringing the HP-55 (and your "HP-55") in here! Funny to see how calculators were like back then. In 1982 I had a TI-59 for a while ( no continuous memory, but it had magnetic card reader), then next year something much better: an HP-15C.
At first I thought you had converted the pi program to the "HP-55" like the previous one for the ln(2) series, judging by the picture in your detailed thread on the "HP-55", but then I realized it was the rational approximation 355/113. This one appears in the small HP-35 manual, BTW.

Regards,

Gerson.

03-31-2014, 04:18 AM
Post: #68
 bkn42 Junior Member Posts: 20 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-30-2014 03:51 AM)Gerson W. Barbosa Wrote:  At first I thought you had converted the pi program to the "HP-55" like the previous one for the ln(2) series, judging by the picture in your detailed thread on the "HP-55", but then I realized it was the rational approximation 355/113. This one appears in the small HP-35 manual, BTW.
Its when I started my HP Calculator FPGA project, I first saw the 355/113 approximation for PI in the HP-35 manual. I used it as a first test of my FPGA design.

On a side note, since there is a lot of execution times being posted here, I tried turning up the internal clock rate of my "HP-55". I never designed it for speed just to be functionally equivalent to the classic HPs. However, I was able to get my current design to run at 84MHz (a 3x increase) -- this is not too bad for the FPGA I'm using. Anyway, all the execution times I posted are now one third of what I stated.

Brian
03-31-2014, 06:42 PM
Post: #69
 bkn42 Junior Member Posts: 20 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
I tried the "two-terms-at-a-time" method on my HP-32SII:
Code:
 A01 LBL A A02 0.00002 A03 + A04 1 A05 - A06 STO I A07 0 L01 LBL L L02 RCL I L03 IP L04 ENTER L05 ENTER L06 x L07 + L08 1/x L09 + L10 DSE I L11 GTO L L12 RTN

10000 XEQ A
Yields: 0.69309718306 in about 5min 15sec

Brian
03-31-2014, 07:22 PM
Post: #70
 Thomas Klemm Senior Member Posts: 1,616 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
This might be a little faster:
Code:
L04 ENTER L05 x^2 L06 +

Cheers
Thomas
03-31-2014, 07:49 PM
Post: #71
 bkn42 Junior Member Posts: 20 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-31-2014 07:22 PM)Thomas Klemm Wrote:  This might be a little faster:
Code:
L04 ENTER L05 x^2 L06 +

Cheers
Thomas

Yes, that is a little faster! Run time now is about: 4min 51secs

Brian
03-31-2014, 08:01 PM
Post: #72
 Gerson W. Barbosa Senior Member Posts: 1,454 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-31-2014 07:22 PM)Thomas Klemm Wrote:  This might be a little faster:
Code:
L04 ENTER L05 x^2 L06 +

And this is is a little shorter:
Code:
 A01 LBL A A02 0.00002 A03 + A04 STO I A05 0 L01 LBL L L02 RCL I L03 IP L04 ENTER L05 x^2 L06 - L07 1/x L08 - L09 DSE I L10 GTO L L11 RTN

My HP-32SII is slower than Brian's: 5 m 29s here.

Cheers,

Gerson.
03-31-2014, 08:27 PM
Post: #73
 Dave Britten Senior Member Posts: 2,074 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
A very unremarkable version for my Tandy PC-3 (AKA Sharp PC-1251), which uses BASIC:

Code:
10 "L":AREAD C 20 X=0 30 FOR I=C TO 1 STEP -1 40 X=X+(1/I)*((-1)^(I+1)) 50 NEXT I 60 PRINT X 70 END

Switch to RUN mode, enter the number of iterations, and press DEF L to start. I get 100 loops in about 32 seconds, so 10000 would take around 54 minutes. Not an especially fast machine.
03-31-2014, 10:13 PM
Post: #74
 DavidM Senior Member Posts: 849 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
I was impressed with the timings seen on the 42s and 34s using the "two terms at a time" approach. I didn't think a 50g would do as well, so I thought I'd give it a shot to see what might happen.

UserRPL version:
Code:
 \<<    TICKS    0    10000.    1.    FOR n       n DUP 1. - * INV       +    -2. STEP    TICKS ROT - B\->R 8192. / \>>
Final Value: 0.69309718306
Avg. of 5 runs: 42.745 seconds

I was curious as to how different a SysRPL version of this might be, so I tried the following. I've added comments to (hopefully) make it a bit easier to follow the logic.
SysRPL:
Code:
 RPL DEFINE   TotalLAMs         BINT3 DEFINE   RCL_StartTime     3GETLAM DEFINE   STO_n             2PUTLAM DEFINE   RCL_n             2GETLAM DEFINE   STO_sum           1PUTLAM DEFINE   RCL_sum           1GETLAM ::    ( no args required )    CK0NOLASTWD    ( place local vars on stack )    SysTime     ( StartTime )    %% 10000    ( n )    %%0         ( sum )    ( bind local vars )    NULLLAM TotalLAMs NDUPN DOBIND    ( loop counter - do [n/2] times )    RCL_n %%>% COERCE #2/    ( main loop )    #1+_ONE_DO (DO)       ( determine current expression value )       RCL_n DUP %%1 %%- %%* %%1/       ( add value to running sum )       RCL_sum %%+ STO_sum       ( decrement n by 2 )       RCL_n %%2 %%- STO_n    LOOP    ( convert extended real to user real )    RCL_sum %%>%    ( determine run time )    SysTime RCL_StartTime bit- HXS>% % 8192 %/    ( release local var bindings )    ABND ;
Final Value: 0.69309718306
Avg. of 5 runs: 20.318 seconds

Not surprisingly, the SysRPL version was noticeably faster. But still not as good as the 42s/34s versions.

Besides the speed difference, the SysRPL version also affords the opportunity to see the 15-digit result of the sum if you don't do the final conversion:
0.693097183059944 (it actually displays as "6.93097183059944E-1"). "Extended Reals" are of no use outside the context of a running SysRPL code object, but it's nice to see all the digits that were retained in the calculations.
04-01-2014, 02:57 AM
Post: #75
 Gerson W. Barbosa Senior Member Posts: 1,454 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-31-2014 10:13 PM)DavidM Wrote:  I was impressed with the timings seen on the 42s and 34s using the "two terms at a time" approach. I didn't think a 50g would do as well, so I thought I'd give it a shot to see what might happen.

UserRPL version:
Code:
 \<<    TICKS    0    10000.    1.    FOR n       n DUP 1. - * INV       +    -2. STEP    TICKS ROT - B\->R 8192. / \>>
Final Value: 0.69309718306
Avg. of 5 runs: 42.745 seconds

I was curious as to how different a SysRPL version of this might be, so I tried the following. I've added comments to (hopefully) make it a bit easier to follow the logic.
SysRPL:
Code:
 RPL DEFINE   TotalLAMs         BINT3 DEFINE   RCL_StartTime     3GETLAM DEFINE   STO_n             2PUTLAM DEFINE   RCL_n             2GETLAM DEFINE   STO_sum           1PUTLAM DEFINE   RCL_sum           1GETLAM ::    ( no args required )    CK0NOLASTWD    ( place local vars on stack )    SysTime     ( StartTime )    %% 10000    ( n )    %%0         ( sum )    ( bind local vars )    NULLLAM TotalLAMs NDUPN DOBIND    ( loop counter - do [n/2] times )    RCL_n %%>% COERCE #2/    ( main loop )    #1+_ONE_DO (DO)       ( determine current expression value )       RCL_n DUP %%1 %%- %%* %%1/       ( add value to running sum )       RCL_sum %%+ STO_sum       ( decrement n by 2 )       RCL_n %%2 %%- STO_n    LOOP    ( convert extended real to user real )    RCL_sum %%>%    ( determine run time )    SysTime RCL_StartTime bit- HXS>% % 8192 %/    ( release local var bindings )    ABND ;
Final Value: 0.69309718306
Avg. of 5 runs: 20.318 seconds

Not surprisingly, the SysRPL version was noticeably faster. But still not as good as the 42s/34s versions.

There was a mistake in my reply to Werner which has now been fixed (14 minutes 59 seconds, not 14.59 seconds, which means the two terms at a time version might take about 8 minutes). The HP-42S can never be faster than the HP 50g. Sorry for the confusion!

98.85 seconds on my HP-48GX, and 46.97 seconds on my HP 50g, timed with TEVAL:

Code:
 %%HP: T(3)A(D)F(,); \<< TICKS 0 ROT DUP 2 / 1 SWAP   START DUP DUP 1 -                         ; on the HP 50g, DUPDUP * INV ROT + SWAP 2 -   NEXT DROP TICKS ROT - B\->R 8192 / \>>

Gerson.
04-01-2014, 03:54 AM
Post: #76
 DavidM Senior Member Posts: 849 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(04-01-2014 02:57 AM)Gerson W. Barbosa Wrote:  ...(14 minutes 59 seconds, not 14.59 seconds, which means the two terms at a time version might take about 8 minutes). The HP-42S can never be faster than the HP 50g. Sorry for the confusion!

I don't own or have access to a 42s, so I wasn't sure. I will confess, however, that I was a bit suspicious about at 14.59 second timing on a calculator with those specs. Thanks for the clarification.
04-01-2014, 06:50 AM
Post: #77
 HP67 Senior Member Posts: 655 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(03-31-2014 10:13 PM)DavidM Wrote:  Not surprisingly, the SysRPL version was noticeably faster. But still not as good as the 42s/34s versions.

If I understood what you did your User RPL version only uses the stack but your Sys Rpl version uses local variables pretty heavily. I would bet the Sys Rpl version could be tweaked to run a lot faster from the stack.

It ain't OVER 'till it's 2 PICK
04-01-2014, 08:32 AM
Post: #78
 DavidM Senior Member Posts: 849 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(04-01-2014 06:50 AM)HP67 Wrote:  If I understood what you did your User RPL version only uses the stack but your Sys Rpl version uses local variables pretty heavily. I would bet the Sys Rpl version could be tweaked to run a lot faster from the stack.

You might be surprised.

My first attempt at creating the SysRPL version was entirely stack based:
Code:
    SysTime         %%0     %% 10000          DUP %%2 %%/>% COERCE     #1+_ONE_DO (DO)         DUPDUP %%1 %%- %%* %%1/ ROT %%+         SWAP %%2 %%-     LOOP          DROP %%>%          SysTime ROT bit- HXS>% % 8192 %/

It was very close to the same speed as the local vars version, but very slightly slower. I'm talking about hundredths of a second when averaged over 5 runs. If I ran them both 20 times, I'm not sure which one would have come out ahead. In the end, the local vars version was easier to read (and follow), so I posted that one.

This may not seem intuitive to some, but the use of null-named locals (as I used in the first SysRPL example I posted) as opposed to named locals (which is what you get with standard UserRPL) is significant. Null-named locals are very efficient; they are accessed via an index into a table instead of being searched out by matching a string. This means that recalling/storing null-named variables is very fast. If you can avoid some stack manipulation steps by using null-named local variables, you're likely to see a time savings as a result. Additionally, your code will be much easier to understand and maintain when you can use locals as opposed to manipulating everything on the stack.

In this case, it's nearly even in terms of time. Both versions are fairly easy to understand. In larger projects, it becomes a no-brainer IMHO. When it's close in performance, code clarity (and thus maintainability) wins.
04-01-2014, 09:17 AM
Post: #79
 HP67 Senior Member Posts: 655 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
Thank you for the info. From your description of null-named locals it would seem the stack version should still be faster, all else being equal. I'm surprised over 10,000 iterations it didn't have more impact.

It ain't OVER 'till it's 2 PICK
04-01-2014, 07:37 PM
Post: #80
 DavidM Senior Member Posts: 849 Joined: Dec 2013
RE: Programming Exercise (HP-15C, 15C LE - and others)
(04-01-2014 09:17 AM)HP67 Wrote:  From your description of null-named locals it would seem the stack version should still be faster, all else being equal. I'm surprised over 10,000 iterations it didn't have more impact.

Looking at the two versions, the stack version of the loop actually has fewer steps. So I also thought that the stack version would be faster when I first coded it. But the most time-consuming operations in the loop are the computations, not the stack manipulations. Moving pointers around is practically inconsequential when compared to the time involved to compute the inverse of an extended real BCD value (or the sum or product, etc.). The most time-hungry parts of the two loops are exactly the same (-,*,1/x,+,-). That's why the timings are so close; the two versions spend the bulk of their time doing essentially the same steps.

To check my sanity, I did some more testing of these two versions. I created another code object which ran both versions (one after the other) in a loop of 20 iterations. On an emulated 50g (Emu48 1.53+), the stack-based version was faster than the local vars version on 18 of 20 iterations. When I ran the exact same test on my real 50g, the local vars version was faster 16 of 20. In both tests, the differences were minor.

To me, that means that the two versions are so close in speed that other idiosyncrasies of the system (intermittent garbage collection, nibble-alignment, interrupt handling, clock irregularities, etc.) are what's making the difference between the two.
 « Next Oldest | Next Newest »

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