09-22-2019, 11:10 AM

09-22-2019, 05:02 PM

From David Ramsey:

Quote:HHC 2019 Programming Contest

Your mission, should you decide to accept it, is to write a program that finds all 3-digit numbers equal to the sums of the cubes of their digits. This is a simple problem but there are many optimizations possible for doing this on a programmable calculator.

As an example, the number 153 would qualify, since:

1x1x1 = 1

5x5x5 = 125

3x3x3 = 27

and 1+125+27 = 153

There are four numbers that satisfy this condition.

This program requires no input and the output should consist of the four numbers. It's assumed that RPN calculators will be HP-41, HP-42S, or SwissMicros variations such as the DM42.

Da Rulez

RPN and RPL calculators: Programs must be started by pressing R/S or a defined function or label key. When the program completes the four numbers should be on the stack.

Prime calculators: Do it your way. I don't know nuthin' about no Primes.

65/97/15C calculators: It can be done. Impress me.

Your contest entry should consist of a calculator with your program installed and ready to run, and a listing of the program. Comments are appreciated in the source.

Programs will be judged on speed, efficiency, and sheer algorithmic cleverness. The definitions of these terms are teh sole province of the judges. No appeals. There may be prizes, depending on what I can find interesting in my junk pile.

09-22-2019, 05:46 PM

Thanks, Eric. When is the submittal deadline?

09-22-2019, 06:50 PM

I forget, is SysRPL allowed on these contests?

09-22-2019, 09:02 PM

(09-22-2019 05:02 PM)Eric Rechlin Wrote: [ -> ]From David Ramsey:

Quote:HHC 2019 Programming Contest

...

Da Rulez

RPN and RPL calculators: Programs must be started by pressing R/S or a defined function or label key. When the program completes the four numbers should be on the stack.

...

A list with the four numbers on the stack doesn’t look out of the rules to me. Anyway, 2.5 bytes more wouldn’t make any difference on my already lengthy RPL code (237 bytes). Also, almost half a minute (29.7 seconds) seems a lot of time on the 50g. I have to leave now, so I won’t be able to try a better algorithm. I am looking forward for the nice solutions you all are working on.

09-22-2019, 10:05 PM

Hi, Eric:

(09-22-2019 05:02 PM)Eric Rechlin Wrote: [ -> ]From David Ramsey:

Quote:HHC 2019 Programming Contest. [...]write a program that finds all 3-digit numbers equal to the sums of the cubes of their digits.

This article o'mine includes a solution (Task 1) for both the HP-41C (RPN, 39 steps) and the SHARP PC-1211 (BASIC, 2 lines:

Know Thy Foe: A New Contender

Also, I give a general solution for 1 to 11 digits for the HP-71B (BASIC, 12 lines) in my Short & Sweet Math Challenges #23: "May the 4th Be With You !" Special., just do a REV$ of every solution found. I also discuss there the details on how to efficiently find the solutions for that many digits in reasonable times.

Regards.

V.

09-22-2019, 10:48 PM

Code for HP-42S or HP-41C:

Nothing very clever or elegant, I'm afraid, but it gets the job done, taking 10 minutes and 30 seconds to return 153, 370, 371, and 407, on my HP-42S.

Code:

`00 { 72-Byte Prgm }`

01▸LBL "QD"

02 2

03 STO 01

04 10↑X

05 STO 00

06▸LBL 00

07 0

08 RCL 00

09▸LBL 01

10 RCL ST X

11 10

12 STO÷ ST Z

13 MOD

14 ENTER

15 X↑2

16 ×

17 RCL ST Z

18 +

19 X<>Y

20 IP

21 X≠0?

22 GTO 01

23 R↓

24 RCL 00

25 X≠Y?

26 GTO 02

27 STO IND 01

28 1

29 STO+ 01

30▸LBL 02

31 1

32 STO+ 00

33 RCL 00

34 1ᴇ3

35 X>Y?

36 GTO 00

37 1/X

38 1

39 -

40 STO+ 01

41▸LBL 03

42 RCL IND 01

43 DSE 01

44 GTO 03

45 END

Nothing very clever or elegant, I'm afraid, but it gets the job done, taking 10 minutes and 30 seconds to return 153, 370, 371, and 407, on my HP-42S.

09-22-2019, 11:39 PM

(09-22-2019 09:02 PM)Gerson W. Barbosa Wrote: [ -> ]Also, almost half a minute (29.7 seconds) seems a lot of time on the 50g.

Sticking to my first – and usually worst – idea, now only slightly faster (25.6 seconds) and longer (254.5 bytes).

{153. 370. 371. 407.}

Code:

« { } 0. 9.

FOR i i +

NEXT 3. ^ { } 2. 10.

FOR h h 1. - 100. * 1. 10.

FOR t t 1. - 10. * 1. 10.

FOR u ROT PICK3 PICK3 + u 1. - + 5. PICK DUPDUP u GET ROT

t GET ROT h GET + + DUP UNROT == { + } { DROP } IFTE UNROT

NEXT DROP

NEXT DROP

NEXT NIP

»

09-23-2019, 03:08 AM

Here are my smallest and my fastest 50g entries:

smallest:

95 bytes

128 sec

and fastest

154 bytes

21.4 sec

smallest:

95 bytes

128 sec

Code:

«

100 DUP 999 START

DUPDUP

10 MOD

LASTARG / 10 MOD

LASTARG /

3. ->LIST IP 3. ^ sigmaLIST

== OVER IFT 1. +

NEXT

DROP

»

and fastest

154 bytes

21.4 sec

Code:

«

1. 9. FOR h

0. 9. FOR t

0. 9. FOR o

h 100. * t 10. * + o +

h DUPDUP * * t DUPDUP * * + o DUPDUP * * +

IF OVER not= THEN

DROP

END

NEXT NEXT NEXT

»

09-23-2019, 01:54 PM

My take, nothing clever here, just plain brute force. I had solved this previously, I found this code already in my calc I guess from some old challenge?.

Anyway, the trivial code was also in my calc already and Wes already posted it, so I won't repeat it. I do want to post this other version which splits the digits from a single loop.

Is quite straightforward, uses the newRPL-only DIGITS command to extract digits off a number ( <number> <start_digit> <end_digit> DIGITS):

This version runs in 0.097 seconds, while Wes fastest runs in 0.068 seconds. That's when run from within a program, if executed from the keyboard it's 0.556 seconds and 0.531 seconds respectively due to power-saving clock management.

Anyway, the trivial code was also in my calc already and Wes already posted it, so I won't repeat it. I do want to post this other version which splits the digits from a single loop.

Is quite straightforward, uses the newRPL-only DIGITS command to extract digits off a number ( <number> <start_digit> <end_digit> DIGITS):

Code:

«

100 999 FOR 'K'

K 0 0 DIGITS 3 ^

K 1 1 DIGITS 3 ^ +

K 2 2 DIGITS 3 ^ +

IF K == THEN K END

NEXT

»

This version runs in 0.097 seconds, while Wes fastest runs in 0.068 seconds. That's when run from within a program, if executed from the keyboard it's 0.556 seconds and 0.531 seconds respectively due to power-saving clock management.

09-24-2019, 02:22 AM

Regarding this year's programming contest:

0. Previous programming contests had sometimes been, IMO, needlessly difficult. Perhaps that's because I'm not a mathematician or algorithm wonk, but I recall years in which I could not even formulate an approach. So I wanted to make this year's contest conceptually simple with the idea being optimization.

1. But if I ever did it again, I'd probably restrict it to a single calculator architecture. The solution is trivial and uninteresting for a Prime; I was more interested in the optimizations people could find for RPN keystroke programmables. For example, large classes of numbers can be eliminated from consideration-- for example, numbers that have two "9" digits-- but the tests for these numbers can take as much or more time than simply checking the number. Stuff like that. As it was I had to dragoon Joe Horn into helping judge the RPL submissions, since I don't do no RPL.

2. Also, I'd give less information on the solution. Several people "optimized" their programs by having them stop after four results were found, since I'd specifically said there were four numbers that satisfied the "three digit numbers equal to the sum of the cubes of their digits." This wasn't really what I was looking for but it was within the rules, so...

3. I'd like to have objective criteria programs can be measured against. The problem is that even if the contest is restricted to, say, RPN calculators, the performance delta between a 15 or 41 and something like a DM-42 or 41CL makes a pure performance metric unrealistic. Same goes for size-- newer machines have instructions and capabilities that can collapse the number of steps required. As it was I had "Classic RPN" and "Modern RPN" categories.

Suggestions on a more equitable contest would be appreciated by whomever does the contest next year, I'm sure!

0. Previous programming contests had sometimes been, IMO, needlessly difficult. Perhaps that's because I'm not a mathematician or algorithm wonk, but I recall years in which I could not even formulate an approach. So I wanted to make this year's contest conceptually simple with the idea being optimization.

1. But if I ever did it again, I'd probably restrict it to a single calculator architecture. The solution is trivial and uninteresting for a Prime; I was more interested in the optimizations people could find for RPN keystroke programmables. For example, large classes of numbers can be eliminated from consideration-- for example, numbers that have two "9" digits-- but the tests for these numbers can take as much or more time than simply checking the number. Stuff like that. As it was I had to dragoon Joe Horn into helping judge the RPL submissions, since I don't do no RPL.

2. Also, I'd give less information on the solution. Several people "optimized" their programs by having them stop after four results were found, since I'd specifically said there were four numbers that satisfied the "three digit numbers equal to the sum of the cubes of their digits." This wasn't really what I was looking for but it was within the rules, so...

3. I'd like to have objective criteria programs can be measured against. The problem is that even if the contest is restricted to, say, RPN calculators, the performance delta between a 15 or 41 and something like a DM-42 or 41CL makes a pure performance metric unrealistic. Same goes for size-- newer machines have instructions and capabilities that can collapse the number of steps required. As it was I had "Classic RPN" and "Modern RPN" categories.

Suggestions on a more equitable contest would be appreciated by whomever does the contest next year, I'm sure!

09-24-2019, 02:57 AM

I thought it was an interesting challenge, and well suited to RPN calculators. Even though I was disappointed in what I came up with in the end, the process of looking for ways to shave off a line here or there, or save a register by using stackrobatics, reminded me of the days when this whole hobby started, programming the HP-25. Good times. Thank you!

09-24-2019, 03:02 AM

David, welcome to the world of Programming Contests. :-)

I learned most of those lessons myself over the last 10 years. As to needlessly complicated, perhaps. :-) My problem has been that when something turned out to be easy, most of the solutions looked nearly the same. I had someone complain it was too easy one year...so I have found it very hard to balance!

That's one reason I went with the personal aspect of determining a small straight for my yahtzee game the last time. Very useful for me. :-)

Thanks for putting on this year's conference and for doing a programming contest!

I learned most of those lessons myself over the last 10 years. As to needlessly complicated, perhaps. :-) My problem has been that when something turned out to be easy, most of the solutions looked nearly the same. I had someone complain it was too easy one year...so I have found it very hard to balance!

That's one reason I went with the personal aspect of determining a small straight for my yahtzee game the last time. Very useful for me. :-)

Thanks for putting on this year's conference and for doing a programming contest!

09-24-2019, 03:58 AM

It was good to see the programming contest problem posted, however, it came way too late. The problem seemed like a good one and not so obscure as some in recent years. If it had been posted on Saturday morning there is a good chance I would have come up with an entry.

09-24-2019, 04:23 AM

(09-24-2019 03:58 AM)Brian Walsh Wrote: [ -> ]It was good to see the programming contest problem posted, however, it came way too late. The problem seemed like a good one and not so obscure as some in recent years. If it had been posted on Saturday morning there is a good chance I would have come up with an entry.

Brian, I guess I just don't understand why it matters when the problem statement was posted online. You can always develop and refine your own solution without regard to what others have done. I thought about developing a solution for a specific calculator but decided against it, but not because I saw what others had done. To me, the joy in this activity is developing my own solution and then optimizing it based on either speed or size or some other criteria. For example, on the 12c I like to optimize by having no wasted space GOTO 00 lines at the end.

09-24-2019, 04:52 PM

Of course the ultimate solution in terms of size and speed has yet to be posted...

Code:

`\<< 153. 370. 371. 407. \>>`

09-24-2019, 06:17 PM

I am surprised how many people think this is a legitimate solution, given that the rules said:

"...write a program that finds all 3-digit numbers equal to the sums of the cubes of their digits."

I can't see how finding these four numbers using outside methods or another program, and then submitting a program that simply puts those four numbers on the stack, qualifies at all.

Fortunately nobody actually submitted such a solution...

"...write a program that finds all 3-digit numbers equal to the sums of the cubes of their digits."

I can't see how finding these four numbers using outside methods or another program, and then submitting a program that simply puts those four numbers on the stack, qualifies at all.

Fortunately nobody actually submitted such a solution...

09-24-2019, 06:41 PM

(09-24-2019 04:23 AM)Don Shepherd Wrote: [ -> ]Brian, I guess I just don't understand why it matters when the problem statement was posted online. You can always develop and refine your own solution without regard to what others have done. I thought about developing a solution for a specific calculator but decided against it, but not because I saw what others had done. To me, the joy in this activity is developing my own solution and then optimizing it based on either speed or size or some other criteria. For example, on the 12c I like to optimize by having no wasted space GOTO 00 lines at the end.It's simply that timeliness of posting the challenge is what matters to those who want to submit contest entries.

09-24-2019, 07:05 PM

Somewhat related to discussions at the conference about the HP Prime G2 availability, Rakuten currently offers a 15% coupon (code: SAVE15) and free shipping, for a total of $130.89.

https://www.rakuten.com/shop/american-te...=2AP18AA-N

https://www.rakuten.com/shop/american-te...=2AP18AA-N

09-24-2019, 07:06 PM

I actually think most of those wanting to submit entries couldn't care less about the contest itself. We see it as a mini challenge, "me against the algorithm", not really competing against anybody, just sharing different thoughts with the sole objective of removing some of the rust in our brains, that's all.

I think the people that create the contests sees it that way too, it's more good sportsmanship than competition. It's OK if it was posted later, don't be disappointed, just solve the problem and post your solution, even late it's OK.

I think the people that create the contests sees it that way too, it's more good sportsmanship than competition. It's OK if it was posted later, don't be disappointed, just solve the problem and post your solution, even late it's OK.