Another couple of practical speed tests for the 15c

[Jose Gonzalez Divasson]

Here are another couple of practical speed tests for the 15c

Blog - practical speed tests

[Paul Berger (Canada)]

I wrote a program to find 4 digits numbers such that A^B * C^D = ABCD I used the same algorithm on several calculators from a 41 up to a 50G and I even plowed into sysRPL for the first time and wrote a sysRPL version of the program. When I got my 15C LE I ported the 41 version of the program over to it and the result is the program on the 15C LE is almost as fast as the sysRPL program on the 50G. Since this was my first try at sysRPL it may not be the most efficient program possible but still this says a lot for the speed of 15C LE. If anyone is interested I can post all the results. I am currently attempting to port the algorithm over to a TI-59 but it is hard going, it has been many years since I programmed a TI and there are subtle differences in the way they handle thing plus of course its not RPN.

[Chris Randle (UK)]

Interested.

I'm tinkering with sysRPL at the moment, so I'd like a benchmark timing to have something to aim for.

[Paul Berger (Canada)]

My program is basically 4 nested loops, one loop for each digit in the number, with the thousands being the outer loop and units the inner loop. It is not completely brute force it eliminates any values wher the x^y would be greater than the value tested, this test is not perfect and does eliminate number that are potential candidates, however it does come up with the right answer, it also eliminate any 0^x values even though some schools of thought say 0^0 =1 but it was easier to ignore this. Even though I know there is only one number that fits the A^B*C^D=ABCD I go through all numbers from 0 to 9999 with the exception noted above.

The results in ascending time order are as follows:

50G    SysRPL 00:01:30

15C LE RPN    00:01:39

50G    UsrRPL 00:02:29

49G    SysRPL 00:03:28

48GX#1 UsrRPL 00:05:58

75C    Basic  00:06:21 

48GX#2 UsrRPL 00:06:24

49G    UsrRPL 00:06:39

71B    Basic  00:08:57

28S    UsrRPL 00:12:40

28C    UsrRPL 00:18:20

41CV   RPN    01:36:28

Things I learned from this exercise:

1. It takes a lot more statements to create a SysRPL program, you would really want to have a need for the extra speed to even bother.

2. Learning curve to get started with SysRPL is even steeper than UsrRPL and it is not as well documented.

3. I found writing UsrRPL pretty straight forward and since I have some programming experience it makes sense to me.

4. The memory in the 28C really is pitifully small I could not even save the program after editing it , there seemed to be enough free space but it would tell me there was no room.

5. Having a a powered on peripheral printer attached to a 41 has a very significant impact on the run time of a program, it appears that it keep checking the state of the switches on the printer as I could start and stop trace while it was running, a HPIL attached printer had no effect.

6. I wrote a version of the program for a TI-59, after using HP calculators for several years now, and being used to how they operated, it was painful to go back to program a TI and compared to the HP41 it took almost twice as many step to accomplish the same thing, and after 02:19:51 it failed to find the answer.



Notes:

1. I listed two 48GXs as one seems to be about 6% faster than the other, it seemed like a big variation to me.

2. Timing for the 41CV, 28C, 28S and 15C LE where measured using a stop watch, timing for all others was measured by the calculators clock.

[Marcus von Cube, Germany]

This would be a nice exercise on WP 34S in integer mode. I'd assume this will be the fastest. In real mode, the 34S might be even slower then the 15C LE because logs are slow.

[Paul Dale]

I imagine it would be much faster. Integer mode doesn't use logs for y^x. It does it in a cleverer way :-) Additionally, integer logs are fast.

- Pauli

[Paul Dale]

I've quickly coded this for the 34S. In 2's complement 64 bit integer mode, it takes 8.7 seconds to iterate fully over the range of possibilities. In real mode it takes a lot longer: 451.9 seconds (7 minutes 31.9 seconds). Those logarithms are hurting us lot.

The unique result is returned in register 30 and the number of TICKS in X.

I've made no real attempt to prune the search space here so I'm confident it can be sped up some more.

- Pauli

001 /*      */ LBL A

002 /*      */ TICKS

003 /*      */ STO K

004 /*      */ 9			

005 /*      */ STO D

006 /*      */ STO 00

007 /*      */ INC X

008 /*      */ STO J			

009 /* l0:: */ RCL 00

010 /*      */ RCL[times] J

011 /*      */ STO 10

012 /*      */ RCL D

013 /*      */ STO 01

014 /* l1:: */ RCL 10

015 /*      */ RCL+ 01

016 /*      */ RCL[times] J

017 /*      */ STO 11

018 /*      */ RCL 00

019 /*      */ RCL 01

020 /*      */ y[^x]

021 /*      */ STO 20

022 /*      */ RCL D

023 /*      */ STO 02

024 /* l2:: */ RCL 11

025 /*      */ RCL+ 02

026 /*      */ RCL[times] J

027 /*      */ STO 12

028 /*      */ RCL D

029 /*      */ STO 03

030 /* l3:: */ RCL 12

031 /*      */ RCL+ 03

032 /*      */ RCL 02

033 /*      */ RCL 03

034 /*      */ y[^x]

035 /*      */ RCL[times] 20

036 /*      */ x=? Y

037 /*      */ STO 30

038 /*      */ DSL 03

039 /*      */ BACK 09 // JMP l3

040 /*      */ DSE 02

041 /*      */ BACK 17 // JMP l2

042 /*      */ DSL 01

043 /*      */ BACK 29 // JMP l1

044 /*      */ DSE 00

045 /*      */ BACK 36 // JMP l0

046 /*      */ TICKS

047 /*      */ RCL- K

048 /*      */ RTN

[Paul Berger (Canada)]

Taking the filter out of my 15C LE program increases the run by almost one minute to 2' 28".

[Kiyoshi Akima]

I must be doing something wrong, since my first brute-force program for the 15C+ found the solution in 1:12. A minor but possibly cheating optimization brought the time down to fifteen seconds.

UserRPL on the 50g did it in 23 seconds, down to 13 in SysRPL. The current champion is the 30b at 3 seconds.

[Paul Berger (Canada)]

Impressive, I would be interested in seeing your programs.

[Kiyoshi Akima]

You have mail.

It's not ready for public consumption. Give me the weekend to polish it up and I'll post it then.

[Paul Berger (Canada)]

Now that I re-read your post I see the difference your time is for finding the result. My program tests all reasonable possibilities from 0000 - 9999 except 0^x that is ignored and also when it finds A^B > AB00 it skips to the next value of B and if C^D > AB00 it skips to the next value of D. As I am writing this it occurs to me that in the first case I could skip to the next value of A right away since the value B is incrementing if A^B > AB00 then A^(B+1) will certainly be larger too, and the same thing would apply for C & D. When this problem was originally posted it was not revealed that there was only one 4 digit number that would satisfy A^B*C^D = ABCD so it was necessary to check all 4 digit numbers.

[Kiyoshi Akima]

Back to the drawing board...

Okay, I'll revise my programs to find all numbers. So far the 15C+ did it in 1:28 and the HP 50g 1:09 in SysRPL. That's brute-force, without any filtering.

[Paul Berger (Canada)]

If you wish I could provide you with a listing of my program, I don't have a WP34S at this time, but I understand the programming model is similar to 41 and 15C.

[Marcus von Cube, Germany]

A listing would be fine. Porting shouldn't be a problem.

[Paul Berger (Canada)]

You have mail...

[Reth]

I wander how come speed is so important for a pocket calculator used mainly for crunching numbers?