HHC 2014 Programming Contest
|
09-28-2014, 12:16 AM
Post: #21
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-27-2014 07:44 PM)Don Shepherd Wrote: I would say Dec 31 to Jan 1 of the following year is out-of-scope and should not be tested. Actually, it has to be tested for, since a "PDP Date" is defined as any date in a Prime Date Pair, and the program must return all the "PDP Dates" in the given year... even if one of those PDP Dates is Jan 1 or Dec 31. That little complication was an intentional part of this mini-challenge, just for fun. <0|ɸ|0> -Joe- |
|||
09-28-2014, 11:58 AM
Post: #22
|
|||
|
|||
RE: HHC 2014 Programming Contest
Maybe I am misunderstanding something in the format but it appears that there may be up to 30 entries missing from your table. I get 1057 pairs in the 1583 - 9999 range and you get 1027.
These are the earlier of the 2 dates for the ones that appear to be missing. I hand checked a few (only one shown) to ensure that my program wasn't doing something wacky. Code:
Am I missing something? Here is my complete list. It took somewhat longer than my estimate to run (10377 s instead of 8400 s) and yielded a few PDPs fewer than my estimate (1057 instead of 1122 +/- 50). Note that, due to the STD formatting on the 50G, the years ending with 0 are truncated -- 0-extend as required. Code:
I used a crappy little Perl script to reformat both data sets and run the comparision: Code:
|
|||
09-28-2014, 01:39 PM
Post: #23
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-27-2014 04:47 PM)Neil Hamilton Wrote: I gave this a shot in RPL. First attempt yielded 70 s/yr on a 49G+, not too good. This scanned EVERY day of the year (some twice!). Fairly brain dead...The criteria for the contest was for size only. Runtime didn't matter. My winning entry also scanned every date in the year plus 12/31 of the previous year and 1/1 of the next. It was slower than a turtle going uphill but that didn't matter. I'll post it when I have some time and the source code nearby. Dave |
|||
09-29-2014, 11:13 AM
Post: #24
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-28-2014 01:39 PM)David Hayden Wrote: The criteria for the contest was for size only. Actually it did have a few more constraints, "all programs must return the correct answers to qualify" among them. I cannot hope to compete with the Gods of HP Calculators in terms of size or speed. I am nowhere near talented enough. :-) My only goal was to run through ALL the years and see what I got. For that, 70 s/yr -- or even 23 s/yr -- was not going to cut it. That is the main reason I was looking to pick up the speed. Having built a program that was suffiently quick (< 1 s/yr for a small range of years), and having obtained the definitive list, I was a bit surprised that my list was longer than the the definitive one. That is my biggest puzzle right now. I am also wondering why the performance dropped to ~1.25 s/yr when run against a set with an ~8400 year span. The only thing I can think of is that since I push my answers to the stack and with 1000-odd entries on the stack, that might be slowing it down. My output was a string per PDP something like this "31.016401, 1.026401" -- not very compact. Any thoughts? |
|||
09-29-2014, 11:35 AM
Post: #25
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-29-2014 11:13 AM)Neil Hamilton Wrote: I am also wondering why the performance dropped to ~1.25 s/yr when run against a set with an ~8400 year span. The only thing I can think of is that since I push my answers to the stack and with 1000-odd entries on the stack, that might be slowing it down.The large date span probably means that the calculator would do garbage collection at least one, and the items on the large number of items on the stack would make it slow. On the other hand, putting the items in a list would probably be even worse. When you add to a list, it actually creates a new list and copies the old and new items into it. Adding the 877th item copies 866 items, and the new one. So that would probably be even slower. Try dropping the items into a pre-sized array. |
|||
09-29-2014, 12:43 PM
Post: #26
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-28-2014 11:58 AM)Neil Hamilton Wrote: Maybe I am misunderstanding something in the format but it appears that there may be up to 30 entries missing from your table. I get 1057 pairs in the 1583 - 9999 range and you get 1027. ... Am I missing something? (09-29-2014 11:13 AM)Neil Hamilton Wrote: Having built a program that was suffiently quick (< 1 s/yr for a small range of years), and having obtained the definitive list, I was a bit surprised that my list was longer than the the definitive one. That is my biggest puzzle right now. Bill Butler solved this "puzzle" -- I must've accidentally missed a block when I copied & pasted from the UBASIC output. The additional PDP's you found are absolutely correct, and I'll edit them into the "complete list" (hah!) ASAP. Thankfully none of those years were used as test cases for judging the contest. Many thanks for catching the missing PDP's! <0|ɸ|0> -Joe- |
|||
09-29-2014, 01:41 PM
(This post was last modified: 09-29-2014 01:42 PM by Jeff O..)
Post: #27
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-29-2014 12:43 PM)Joe Horn Wrote: Thankfully none of those years were used as test cases for judging the contest. What were the test cases used for judging? Dave - My mind is going - I can feel it. |
|||
09-29-2014, 04:57 PM
Post: #28
|
|||
|
|||
RE: HHC 2014 Programming Contest | |||
09-29-2014, 05:27 PM
Post: #29
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-29-2014 04:57 PM)Thomas Klemm Wrote:(09-28-2014 11:58 AM)Neil Hamilton Wrote:ಠ_ಠ Good eyes, Thomas! OK, I cheated a little bit! The Perl I have on my computer has the majorly annoying feature of sometimes displaying syntax errors as if they were occuring somewhere deep in the bowels of some standard packages rather than showing me where the issue really is -- in my code. I sometimes start to build a script with this turned off and switch it on later. Forgot this time... Put 'my' in front of "$date_format" on lines 95 and 145 (as per my current version) and remove the comment on 'strict' and you are off to the races... The "Joe" file is simply a cut-and-paste of his earlier list. The "Mine" file can be the list I published. Command line could be: Code:
Joe, I suspected that it was simply a few lines were deleted from the output. A cut-and-paste issue makes perfect sense. |
|||
09-30-2014, 01:20 AM
(This post was last modified: 09-30-2014 01:28 AM by Joe Horn.)
Post: #30
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-29-2014 01:41 PM)Jeff O. Wrote:(09-29-2014 12:43 PM)Joe Horn Wrote: Thankfully none of those years were used as test cases for judging the contest. Rats... I seem to have discarded the piece of note paper that the test dates (and expected results) were scribbled on. But I know that none of the missing years were used because I only used years that were in my incomplete table. If I ever find that piece of paper, I'll post the years. EDIT: OOH OOH, I found it! (Doing so caused an avalanche in my room, but I digress). Here are the test years and their expected results: 1586: Oct 31, Nov 1 1588: Aug 31, Sep 1 2014: No PDP's 2020: Dec 31 2021: Jan 1 2080: Feb 29, Mar 1, May 31, Jun 1 2413: Aug 31, Sep 1, Dec 31 2414: Jan 1, Oct 31, Nov 1 3688: Feb 29, Mar 1, Dec 31 7968: Feb 29, Mar 1, Mar 31, Apr 1 <0|ɸ|0> -Joe- |
|||
09-30-2014, 04:39 PM
Post: #31
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-30-2014 01:20 AM)Joe Horn Wrote: EDIT: OOH OOH, I found it! (Doing so caused an avalanche in my room, but I digress). Thanks for the information. (Sorry about the avalanche.) I developed a couple of wp34s versions based on a couple of methods to attack the problem. Happily, they both produce the correct results for the test cases and all other years I have tried from the complete list. One version is 83 steps and reasonably fast. (If the year has no PPDs it finishes in about 1.5 seconds. If there are PPDs, they are displayed sequentially during pauses, so execution time is extended by the pause time for each date.) Second version is 50 steps, but it is much, much slower than the first version, taking about 20 seconds for years with no PPDs. Scanning through the above posts without reading in detail (to avoid hints or ideas), I see that Eric's version is 50 steps and Paul's is only 44. I doubt that my slooowww 50-stepper is comparable to those, so I think I have a ways to go. Guess I’ll keep messing around for a while (for the fun it - which is the point, right?) to see if I can come up with a better way. Dave - My mind is going - I can feel it. |
|||
10-02-2014, 09:35 PM
Post: #32
|
|||
|
|||
RE: HHC 2014 Programming Contest
(09-24-2014 09:31 AM)Paul Dale Wrote: I haven't checked all the myriad of Julian to Gregorian calendar changeovers over the years to see if any of these produced three odd days in a row or not and, if there are some, checked them for primality.In 2011, Samoa skipped a day to jump from behind the International Date Line to be ahead of it (so as to be on the same date as their major trading partners). They did this by skipping December 30th, meaning they had three odd days in a row: 29th then 31st December 2011, followed by 1st January 2012. Fortunately for this competition, none of those dates are prime. :-) |
|||
10-03-2014, 07:35 AM
(This post was last modified: 10-05-2014 06:31 PM by Werner.)
Post: #33
|
|||
|
|||
RE: HHC 2014 Programming Contest
My attempt.
Independent of the date settings, and will run on a 48G or newer. Maybe the elegance and efficiency will make the judges gasp in awe. One can always hope ;-) Code: \<< Cheers, Werner 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
10-05-2014, 10:02 AM
(This post was last modified: 10-05-2014 11:11 AM by C.Ret.)
Post: #34
|
|||
|
|||
RE: HHC 2014 Programming Contest
The version proposed by Werner inspires me and I produce the following codes on my poor HP-28S.
Code: HHC2014: As there is no native ISPRIME?, ISLEAP? or calendar functions on HP28S/C, I have to propose one homebrew version: Code: LEAP?: Code: PRIME?: But this may be the subject of another MPO challenge that will spare batteries! Code: NXTODD: Also, flag 1 have to be clear before the first use of PRIME? (this spare a 1 CF at the beginning of the program) But have any importance only at first use, since the last instruction clear flag 1 whatever the result (cf. FC?C ) |
|||
10-05-2014, 08:02 PM
(This post was last modified: 10-05-2014 08:13 PM by Werner.)
Post: #35
|
|||
|
|||
RE: HHC 2014 Programming Contest
JHM's routine should work if you replace the IFTs by their IF THEN END counterparts:
(untested) Code: \<< Remark that I changed the ultimate test to 1 > This way it will work for 0 and 1, too. I edited my previous post as well. Or else, my own simple concoction. Code: \<< Yet, to speed up the PDP routine, consider the following: If yyyymm01 is prime and the day before isn't, then we have performed a lengthy primality testing for nothing. What we should have is a routine BOTHPRIME? that tests two numbers for divisibility by ever increasing factors at the same time - If both are prime, that will gain us nothing, but if one or both are not, then we will gain a lot of time. I think. How many times does it happen that yyyymm01 is prime and the day before isn't? To be continued.. Werner 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
10-06-2014, 05:01 PM
(This post was last modified: 10-25-2014 01:38 AM by Jeff O..)
Post: #36
|
|||
|
|||
RE: HHC 2014 Programming Contest
Discussion about the 2014 contest seems to have waned a bit, but I'll go ahead and post an update on my progress. I was able to shorten my slow version to 44 steps. I had a slightly faster version at 50 steps. My reasonably fast version was stuck at 83 steps and I did not see any opportunities to improve that by much. I was not particularly satisfied with the shorter versions due to the speed, or the longer version based on length, so I kept on trying to come up with new approaches, thought of one, and developed it. (No earth-shaking insights I'm sure, just different than previous attempts.) I was able to develop a 44 step program that seems as fast as my 83 step version. There may be opportunities to shave a few steps off of that, but I think I'm pretty satisfied at this point. In case anyone is interested, here it is:
Code: YYYY is input year For the heck of it, I converted Neil's listing of prime date pairs to a list of years with at least one PPD and all PPDs in each such year. There are 1121 years between 1583 and 9999 which have at least one Prime Pair Date (i.e. half of a prime date pair). 218 years have one PPD, 839 have two PPDs, 40 have three PPDs, 23 have four PPDs, none have five PPDs, and one year has the maximum of 6 PPDs, that year being 1679. That totals 2114 individual dates that are one-half of a prime pair, which agrees with Neil's total of 1057 prime pairs. The most common prime pair dates are 31-Jan and 01-Feb, occurring 153 times. The others occur with the following frequency: 31-Dec/01-Jan: 129 occurrences 31-Jan/01-Feb: 153 occurrences 29-Feb/01-Mar: 45 occurrences 31-Mar/01-Apr: 151 occurrences 31-May/01-Jun: 146 occurrences 31-Jul/01-Aug: 149 occurrences 31-Aug/01-Sep: 138 occurrences 31-Oct/01-Nov: 146 occurrences 1-Jan and 31-Dec never occur in the same year. Here's the complete list: Code: 1586 31-Oct, 01-Nov **edit** revised version, one step shorter, less clunky display routine. I will leave the original version on which Paul commented above. Code: 001 LBL 'PPD' Label "Prime Pair Dates" **edit 2** I ultimately got around to analyzing Paul's and Eric's versions to see what tips and tricks they used that I likely missed. I discovered similarities, of course. Eric’s posted version, at 50 steps, is a bit longer than the best version I came up with before checking others, but as he noted, it can be easily shortened. A few simple changes (e.g. changing the direct entry of 8800 to CONST #088 SDL 002 and changing the multiplications and divisions by 10000 to SDL 004 and SDR 004) and removing the labels and replacing the GTOs with SKIPs and BACKs reduces it to only 38 steps. After seeing Eric's program, I first applied his technique of adding 100 to the date instead of dividing by 100 and adding 1 to increment the month. That got my program down to 42 steps. I then applied his technique of using flags to handle dates outside of the test year, and came up with what I believe to be the best I can do, 39 steps, with initialization of date mode and finishing with display of the input year. I prefer this to having the program finish with display of first of the following year, because that looks like an output and could confuse the judges :-) Anyhow, here is that version. Code: 001 LBL 'PPD' Label "Prime Pair Dates" **edit 3** A couple more improvements gets it down to 38 steps if the final END is included, while still displaying the input year when the program is done. This could drop to 37 steps if I was satisfied with displaying a zero when done, or 36 steps if the judges were told to ignore the value in the display when the program stops running. This value will either be YYYY1231 or YYYz0101, either of which gives the appearance of an output, so I would prefer to suppress. Code: 001 LBL 'PPD' Label "Prime Pair Dates" Dave - My mind is going - I can feel it. |
|||
10-06-2014, 09:34 PM
Post: #37
|
|||
|
|||
RE: HHC 2014 Programming Contest
(10-06-2014 05:01 PM)Jeff O. Wrote: I was able to develop a 44 step program that seems as fast as my 83 step version. There may be opportunities to shave a few steps off of that, but I think I'm pretty satisfied at this point. Interesting program and great use of the 34S features. One immediate step can be saved -- you don't need the final RTN. A second by omitting the initial label, although that might make reruns harder. - Pauli |
|||
10-07-2014, 12:26 PM
(This post was last modified: 10-07-2014 12:27 PM by Jeff O..)
Post: #38
|
|||
|
|||
RE: HHC 2014 Programming Contest
(10-06-2014 09:34 PM)Paul Dale Wrote: Interesting program and great use of the 34S features. I kept discovering features that helped. Very early versions had a Leap year determination routine. At one point I wondered if wp34s had a leap year function, that saved a ton of steps. Then discovered the Date arithmetic, which eliminates the need for leap year determination altogether as wp34s knows that the day before 01 March is 29 February in leap years. (I knew it had Prime? all along, I never tried to build a prime checking routine.) (10-06-2014 09:34 PM)Paul Dale Wrote: One immediate step can be saved -- you don't need the final RTN. A second by omitting the initial label, although that might make reruns harder. Never thought to check if END works like RTN, just figured it is the separator for alpha labelled programs. Of course, the manual clearly states “Works like RTN in all other aspects.” So I will accept that reduction, although then it seems like we should count the final END statement, so maybe no reduction. I think the label is needed to make it easy on the judges to run multiple test cases. Thanks again for your comments. Jeff Dave - My mind is going - I can feel it. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 12 Guest(s)