Another couple of practical speed tests for the 15c - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: Another couple of practical speed tests for the 15c (/thread-201062.html) Another couple of practical speed tests for the 15c - Jose Gonzalez Divasson - 10-13-2011 Here are another couple of practical speed tests for the 15c Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-13-2011 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. Re: Another couple of practical speed tests for the 15c - Chris Randle (UK) - 10-14-2011 Interested. I'm tinkering with sysRPL at the moment, so I'd like a benchmark timing to have something to aim for. Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-14-2011 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. Re: Another couple of practical speed tests for the 15c - Reth - 10-14-2011 I wander how come speed is so important for a pocket calculator used mainly for crunching numbers? Re: Another couple of practical speed tests for the 15c - Marcus von Cube, Germany - 10-15-2011 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. Re: Another couple of practical speed tests for the 15c - Paul Dale - 10-15-2011 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 Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-15-2011 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. Re: Another couple of practical speed tests for the 15c - Marcus von Cube, Germany - 10-15-2011 A listing would be fine. Porting shouldn't be a problem. Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-15-2011 You have mail... Re: Another couple of practical speed tests for the 15c - Paul Dale - 10-16-2011 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 ``` Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-17-2011 Taking the filter out of my 15C LE program increases the run by almost one minute to 2' 28". Re: Another couple of practical speed tests for the 15c - Kiyoshi Akima - 10-20-2011 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. Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-20-2011 Impressive, I would be interested in seeing your programs. Re: Another couple of practical speed tests for the 15c - Kiyoshi Akima - 10-20-2011 You have mail. It's not ready for public consumption. Give me the weekend to polish it up and I'll post it then. Re: Another couple of practical speed tests for the 15c - Paul Berger (Canada) - 10-20-2011 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. Re: Another couple of practical speed tests for the 15c - Kiyoshi Akima - 10-21-2011 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.