# HP Forums

Full Version: Another couple of practical speed tests for the 15c
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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

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.

Interested.

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

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.

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

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.

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

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.

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

You have mail...

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
```

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

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.

Impressive, I would be interested in seeing your programs.

You have mail.

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

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.

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.