Speed of HP-15C LE - and it's capabilities

[Jeff_Kearns]

I am always amazed at the incredible ingenuity of current and former forum contributors in solving puzzles and mini-challenges, and the various programming techniques used. I would like to tackle the various problems in the Project Euler website one day to see if the HP-15C can handle them all.

I finally got around to entering Valentin Albillo's 160 line program to solve Karl Schneider's A modest arithmetical challenge, posted in April 2007. A worthwhile thread to re-read.

The puzzle involved finding integers from 1 through 9, used exactly once to form three quotients of single-digit integer numerators and two-digit integer denominators, such that the sum of these three terms equals unity. There is only one solution.

The program takes 'a mere' 48 minutes on a physical HP-15C. According to Valentin, a 750x emulator would run this program in less than 4 seconds. So I tried it on the HP-15C LE just now. ... Time: ~20 seconds!!! That is more like 144 times as fast as regular 15C. I am very happy with this calculator, in spite of its bugs, and I regret selling my spare unit last year for a measly $150 (but at least it was sold to a friend who felt he got a good deal) considering what they are going for now, and especially since my 10 year old son is eyeing mine!

Jeff K

[Tugdual]

If I'm not mistaken, you confirmed that the LE is just 100 time faster than the original 15C which is indeed what I found with a much simpler way. I just implemented a loop with a +1 increment and ran and stopped both 15C and 15C LE at the same time. I found that the LE counter was 100 time higher than the 15C counter which I think is pretty representative of the clock speed (not sure if the LE has multiple frequencies depending on the calculation load like the Prime?).
I would be curious to do the same test on the 34s. I already tried a few tests and was very confused by the results. In some occasion the 34s was superior to the LE in some other cases it was the contrary demonstrating a very different approach of apparently similar questions. Also the 15C LE is emulated while the 34s is natively compiled.
If you would like to share your 15C source code I could probably adapt it to the 34s and would be curious to see how it compares.

[Jeff_Kearns]

The HP-15C source code is at the link provided in the original post. It would be nice to see the 34s code also.

(05-13-2014 08:41 PM)Tugdual Wrote:  If I'm not mistaken, you confirmed that the LE is just 100 time faster than the original 15C ...

You may be correct, however according to Valentin's timing of 48 minutes for this particular routine, it is 144x as fast. That wasn't really my point though; I avoided entering the routine at the time because I had no intention of waiting three quarters of an hour to risk discovering I had make a mistake entering the code. It is more fun now than ever.

Jeff

[Gerson W. Barbosa]

(05-13-2014 08:20 PM)Jeff_Kearns Wrote:  I am always amazed at the incredible ingenuity of current and former forum contributors in solving puzzles and mini-challenges, and the various programming techniques used. I would like to tackle the various problems in the Project Euler website one day to see if the HP-15C can handle them all.

I finally got around to entering Valentin Albillo's 160 line program to solve Karl Schneider's A modest arithmetical challenge, posted in April 2007. A worthwhile thread to re-read.

The puzzle involved finding integers from 1 through 9, used exactly once to form three quotients of single-digit integer numerators and two-digit integer denominators, such that the sum of these three terms equals unity. There is only one solution.

The program takes 'a mere' 48 minutes on a physical HP-15C. According to Valentin, a 750x emulator would run this program in less than 4 seconds. So I tried it on the HP-15C LE just now. ... Time: ~20 seconds!!! That is more like 144 times as fast as regular 15C. I am very happy with this calculator, in spite of its bugs, and I regret selling my spare unit last year for a measly $150 (but at least it was sold to a friend who felt he got a good deal) considering what they are going for now, and especially since my 10 year old son is eyeing mine!

Jeff K

My (few) solutions to Valentin's challenges typically used to take about 10 times more than his original ones, but then I surpassed myself: my HP-15C program later in that thread takes 200+ minutes... on the HP-15C LE! :-)

http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=210415


Regards,

Gerson.

[Paul Dale]

The 15C program is message #13 in the link mentioned.

The only problematic bits looks to be the STO RAN# & RCL RAN# which the 34S doesn't support.


Pauli

[Dave Britten]

(05-13-2014 08:20 PM)Jeff_Kearns Wrote:  I am always amazed at the incredible ingenuity of current and former forum contributors in solving puzzles and mini-challenges, and the various programming techniques used. I would like to tackle the various problems in the Project Euler website one day to see if the HP-15C can handle them all.

I'm pretty sure that the 15C wouldn't be able to handle them ALL, as I recall doing at least a few problems that required a pretty substantial* input data set, or some kind of string manipulation.

However, I'd also wager that a very large percentage could be tackled with a non-alphanumeric programmable, as most of them center around finding an algorithm that performs much better than the obvious brute force approach.

(*Substantial for a 15C, at least, unless you want to devise a way to stream-process 10+ KB of manually keyed data. A 41C with enough extra hardware could probably get a lot closer to the "all" mark, and I'm pretty confident the palmtops would have little trouble if you can handle entering that much code on the tiny keyboard.)

[Thomas Klemm]

(05-14-2014 01:37 AM)Paul Dale Wrote:  The only problematic bits looks to be the STO RAN# & RCL RAN# which the 34S doesn't support.

That's probably just used as scratch register for numbers between 0 and 1.

Cheers
Thomas

[Thomas Klemm]

(05-13-2014 08:20 PM)Jeff_Kearns Wrote:  I would like to tackle the various problems in the Project Euler website one day to see if the HP-15C can handle them all.

I'm afraid that you will run soon into problems due to the limited memory. Consider problem 11: How do you want to store 800 digits with only 64 registers? And then, how much is left for the program?

Cheers
Thomas

[Katie Wasserman]

(05-13-2014 08:47 PM)Jeff_Kearns Wrote:  You may be correct, however according to Valentin's timing of 48 minutes for this particular routine, it is 144x as fast. That wasn't really my point though; I avoided entering the routine at the time because I had no intention of waiting three quarters of an hour to risk discovering I had make a mistake entering the code. It is more fun now than ever.

Jeff

In the very long calculation if Pi to 306 digits detailed here, I found the original 15c took 43 hours while the 15cLE took 16.1 minutes. That's a 160x speedup.

[Namir]

Check my YouTube presentation on the HP-15C LE timings at HHC 2011. Here is the link to that presentation.

[Gerson W. Barbosa]

(05-14-2014 04:11 PM)Namir Wrote:  Check my YouTube presentation on the HP-15C LE timings at HHC 2011. Here is the link to that presentation.

Or your article in HP Solve Newsletter "Limited Edition HP 15c
Execution Times", Issue 25, October 2011, page 36:

http://h20331.www2.hp.com/hpsub/download...r_2011.pdf

[Tugdual]

(05-13-2014 08:20 PM)Jeff_Kearns Wrote:  I finally got around to entering Valentin Albillo's 160 line program to solve Karl Schneider's A modest arithmetical challenge, posted in April 2007. A worthwhile thread to re-read.

For some reasons this little problem kept my attention and sorry if I'm a bit off topic now. I suspected there were more solutions than those listed and checked that with a quick and dirty C++ app. Here are my findings.

There are 3 patterns of digits to consider:
P1: d/dd + d/dd + d/dd
P2: dd/dd + d/dd + d/d
P3: dd/ddd + d/d + d/d

P3 doesn't seem to produce results.

Code:

P2 - 1 : 12/48 + 7/36 + 5/9 
P2 - 1 : 12/84 + 5/63 + 7/9 
P2 - 1 : 12/84 + 9/63 + 5/7 
P2 - 1 : 13/52 + 7/84 + 6/9 
P2 - 1 : 14/56 + 9/28 + 3/7 
P2 - 1 : 16/48 + 3/27 + 5/9 
P2 - 1 : 19/72 + 4/36 + 5/8 
P2 - 1 : 19/76 + 3/24 + 5/8 
P2 - 1 : 19/76 + 4/32 + 5/8 
P2 - 1 : 21/49 + 8/56 + 3/7 
P2 - 1 : 21/84 + 7/36 + 5/9 
P2 - 1 : 27/81 + 4/36 + 5/9 
P2 - 1 : 27/81 + 9/54 + 3/6 
P2 - 1 : 29/38 + 4/57 + 1/6 
P2 - 1 : 37/56 + 9/42 + 1/8 
P2 - 1 : 39/52 + 7/84 + 1/6 
P2 - 1 : 39/54 + 8/72 + 1/6 
P2 - 1 : 45/72 + 9/36 + 1/8 
P2 - 1 : 45/76 + 3/19 + 2/8 
P1 - 1 : 5/34 + 7/68 + 9/12 
P1 - 1 : 5/34 + 9/12 + 7/68 
P2 - 1 : 54/81 + 7/63 + 2/9 
P1 - 1 : 7/68 + 5/34 + 9/12 
P1 - 1 : 7/68 + 9/12 + 5/34 
P1 - 1 : 9/12 + 5/34 + 7/68 
P1 - 1 : 9/12 + 7/68 + 5/34

And some C++ snippets for those interested in gory details (using Qt cuz it is so simple but STL on its own would totally do here).

Code:

#include <QDebug>
#include <algorithm>
#include <math.h>

#define ARGS \
    arg(digits.at(0)).arg(digits.at(1)) \
    .arg(digits.at(2)).arg(digits.at(3)) \
    .arg(digits.at(4)).arg(digits.at(5)) \
    .arg(digits.at(6)).arg(digits.at(7)) \
    .arg(digits.at(8))

/*
    somewhere in a function
*/    
    // List of all the digits
    QList<int> digits;

    // Builds the list
    for (int i=1; i<10; i++) digits << i;

    do {
        double v;

        // Pattern 1 (3x3x3)
        v = 0;
        for (int i=0; i<9; i+=3) v += digits.at(i)/(digits.at(i+1)*10.+digits.at(i+2));
        if (fabs(1-v)<1e-5) qDebug() << QString("P1 - %10 : %1/%2%3 + %4/%5%6 + %7/%8%9").ARGS.arg(v);

        // Pattern 2 (4 3 2)
        v  = (digits.at(0)*10.+digits.at(1))/(digits.at(2)*10.+digits.at(3));
        v += digits.at(4)/(digits.at(5)*10.+digits.at(6));
        v += double(digits.at(7))/digits.at(8);
        if (fabs(1-v)<1e-5) qDebug() << QString("P2 - %10 : %1%2/%3%4 + %5/%6%7 + %8/%9").ARGS.arg(v);

        // Pattern 3 (5 2 2)
        v  = digits.at(0)*10.+digits.at(1)/(digits.at(2)*100.+digits.at(3)*10.+digits.at(4));
        v += double(digits.at(5))/digits.at(6);
        v += double(digits.at(7))/digits.at(8);
        if (fabs(1-v)<1e-5) qDebug() << QString("P3 - %10 : %1%2/%3%4%5 + %6/%7 + %8/%9").ARGS.arg(v);

    } while (std::next_permutation(digits.begin(), digits.end()));

[Thomas Klemm]

(05-18-2014 08:49 AM)Tugdual Wrote:  There are 3 patterns of digits to consider:
P1: d/dd + d/dd + d/dd
P2: dd/dd + d/dd + d/d
P3: dd/ddd + d/d + d/d

Quote:form three quotients of single-digit integer numerators and two-digit integer denominators

All your solutions to the P1 pattern are essentially the same:

Quote:

Code:

P1 - 1 : 5/34 + 7/68 + 9/12
P1 - 1 : 5/34 + 9/12 + 7/68
P1 - 1 : 7/68 + 5/34 + 9/12
P1 - 1 : 7/68 + 9/12 + 5/34
P1 - 1 : 9/12 + 5/34 + 7/68
P1 - 1 : 9/12 + 7/68 + 5/34

Cheers
Thomas

[Tugdual]

(05-18-2014 09:25 AM)Thomas Klemm Wrote:  form three quotients of single-digit integer numerators and two-digit integer denominators

I know Was curious to extend...

[Tugdual]

I completed a version of code for the 34s. I started from scratch so don't even try to compare to the 15C version. I doubt my code is optimal, considering its size and the much higher capabilities of the 34s compared to the 15C. Anyway, here is what it looks like.
I tested it on the 34s emulator and the result is pretty quick. On the real 34s it seems to take much more time; I haven't seen the 1st result after 40mn and I think I'm going to stop to avoid draining the battery.
Edit: took around 1h to find a result.

Usage:
Call A to run.
When it stops you'll read:
FOUND
219,867,435
which means (read right to left) 5/34+7/68+9/12
Press R/S to search for the next solution

Code:

001 LBL A
002 1
003 EEX
004 5
005 +/-
006 STO 15
007 8
008 STO 09
009 LBL 00
010 RCL 09
011 STO→09
012 INC→09
013 DSL 09
014 GTO 00
015 LBL 07
016 1
017 ENTER
018 10
019 STO 09
020 RCL 00
021 x Y
022 RCL× 01
023 RCL+ 02
024 /
025 -
026 RCL 03
027 RCL 04
028 RCL× 09
029 RCL+ 05
030 /
031 -
032 RCL 06
033 RCL 07
034 RCL× 09
035 RCL+ 08
036 /
037 -
038 ABS
039 x>? 15
040 GTO 09
041 CLα
042 α'FOU'
043 α'ND'
044 8
045 STO 09
046 CLx
047 LBL 10
048 RCL 09
049 10
050 RCL×→09
051 +
052 DSL 09
053 GTO 10
054 PROMPT
055 LBL 09
056 XEQ 08
057 GTO 07
058 CLα
059 α'END'
060 PROMPT
061 RTN
062 LBL 08
063 8
064 STO 09
065 LBL 01
066 RCL 09
067 STO 10
068 DEC 09
069 RCL→09
070 x≥?→10
071 GTO 05
072 8
073 STO 11
074 LBL 02
075 RCL→09
076 x<?→11
077 GTO 03
078 DEC 11
079 GTO 02
080 LBL 03
081 RCL→11
082 x→09
083 STO→11
084 RCL 10
085 STO 13
086 8
087 STO 14
088 LBL 04
089 RCL 13
090 x≥? 14
091 RTN
092 RCL→13
093 x→14
094 STO→13
095 INC 13
096 DEC 14
097 GTO 04
098 LBL 05
099 RCL 09
100 x≠0?
101 GTO 01
102 0
103 STO 13
104 8
105 STO 14
106 LBL 06
107 RCL 13
108 x≥? 14
109 RTN+1
110 RCL→13
111 x→14
112 STO→13
113 INC 13
114 DEC 14
115 GTO 06
116 END

[Tugdual]

Tested the same problem with the Hp Prime.
Ease of development: much much easier than 34s or 15C, no question about that. Using lists and a few other convenient functions took me less than 1h while on the 34s it took me days of painful debugging. Also when you read the source code, there is a chance that you understand something while the 34s and 15c are quite challenging.

Speed: Prime is the big big winner. 1'51s to find the result! Amazing. You cannot even compare with old gen calculators.

Comments: here again the Prime demonstrates how powerful it is. Still I would use a 34s or 15c on a daily base. Definitely a matter of concept. The Prime seems to be lost somewhere in between a small computer and a calculator, demonstrating a lot of power and programming ease but not convenient for daily calculations.

Code:

next_permutation();

EXPORT permutations()
begin
   local t,v;

   // Initializes the list of digits
   makelist(A,A,1,9,1)▶L1;

   print;
   ticks()▶t;
   repeat
      // Evaluates one combination
      L1(1)/(10*L1(2)+L1(3))+L1(4)/(10*L1(5)+L1(6))+L1(7)/(10*L1(8)+L1(9))▶v;
      if 1-v==0 then 
         print(concat((ticks()-t)/1000,L1));
      end;
   until next_permutation()==0;
END;

// gets next permutation
next_permutation()
begin
LOCAL i,j,k,v;

9▶i;
while(1) do
   i▶j;
   i-1▶i;
   if L1(i)<L1(j) then
      9▶k;
      while(L1(i) >= L1(k)) do k-1▶k; end;
      // swaps item i & k
      L1(k)▶v;  
      L1(i)▶L1(k);
      v▶L1(i);
      // reverse from j to end
      concat(sub(L1,1,j-1), reverse(sub(L1,j,9)))▶L1;
      return 1;
   end;
   if i==1 then
      reverse(L1)▶L1;
      return 0;
   end;
end; // while
end;

[Jeff_Kearns]

(05-25-2014 08:36 AM)Tugdual Wrote:  Tested the same problem with the Hp Prime.

Speed: Prime is the big big winner. 1'51s to find the result! Amazing. You cannot even compare with old gen calculators.

Can you confirm the speed? 1 minute and 51 seconds on the Prime compared to 20 seconds on the 15C-LE is not so impressive.

Jeff K

[Tugdual]

(05-25-2014 01:37 PM)Jeff_Kearns Wrote:  

(05-25-2014 08:36 AM)Tugdual Wrote:  Tested the same problem with the Hp Prime.

Speed: Prime is the big big winner. 1'51s to find the result! Amazing. You cannot even compare with old gen calculators.

Can you confirm the speed? 1 minute and 51 seconds on the Prime compared to 20 seconds on the 15C-LE is not so impressive.

Jeff K

I didn't transpose the 15C algorithm, I transposed the C++ STL next_permutation algorithm. I would rather compare this to the former 34s result, 48mn.

Not sure how the 15C algorithm works, isnt' it brute force?