HHC 2019 will be in Reno, Nevada, Sept 21-22

[dramsey]

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!