HHC 2014 Programming Contest

[Paul Dale]

Joe Horn posted the rules in a different thread.
They are worth linking to again here.

Anyway, on to the nitty gritty.

My first attempt for the 34S follows. The 34S has some advantages here. Date arithmetic and a built in primality tester. It isn't so good at long constants however, I almost wish I'd implemented merged constants which would save lots of steps. Oh well, too late for that now.

The four steps prepended with a minus sign can be removed trivially:

• The initial label is obviously optional.
• LBL 01 is a subroutine called from one place. Make that a BACK branch instead and the RTN+1 statements become a SKIP branch to the instruction after the LBL 03 position.
• LBL 03 is a target of a single branch. Use a SKIP instead.
• CLx is a visual indication that the program has finished, more for debugging than anything else.
  

That makes forty steps. Not a bad first stab at the solution but I very much doubt this is even remotely close to the minimal.


- Pauli

Code:

-    1  LBL A
     2          STO I           Need to seed this register to something small
     3          RCL X           Duplicate the input to give us a stopping value
     4          DEC X           Go back to December 31st of the previous year
     5          SDL 003                 this takes six steps and could probably
     6          # 123                   be improved.  We want (y-1)*10000+1231
     7          +                       which is 10000 y - 8769.  On the 34S
     8          SDL 001                 this takes the same number of steps
     9          INC X                   unless a short cut can be found
    10          RCL Y           Get our year back
    11          INC X           This time we go to Jan 1st of the following year
    12          SDL 004                 I.e. y * 10000 + 101
    13          # 101
    14          +
    15          CF 00           Clear our flag
    16          PRIME?
    17                  SF 00   But set it if Jan 1st is prime.
    18          GTO 03          Skip to the date decrementer

-   19  LBL 01                  Got a prime, check for twin
    20          FC? 00
    21                  STO I   Save if we've not had a prime before
    22          FC?S 00
    23                  RTN+1           and return one step ahead
    24          x[<->] I
    25          XEQ 02          Get previous value and display
    26          x[<->] I
    27          XEQ 02          Display current value
    28          RTN+1           Return with skip

    29  LBL 00                  Main loop check the date
    30          PRIME?
    31                  XEQ 01  If it is prime, do stuff
    32          CF 00           Not prime, clear our twin flag
-   33  LBL 03                  Step back a day
    34          SDR 004                 The 34S only has yyyy.mmdd not
    35          1                       the desired yyyymmdd.  Maybe in the 43S
    36          +/-
    37          DAYS+
    38          SDL 004
    39          x[>=]? Y        Check for loop termination
    40                  GTO 00
-   41          CLx             Visual indication of finished

    42  LBL 02                  Display if in range
    43          x>? Y
    44                  STOP    Use a PSE for less interaction

[Paul Dale]

As for the three challenge questions at the end.



Spoilers here.

1. The first one is straightforward: a prime triple would require three odd numbered days in a row. Clearly not possible in normal years.
   
   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.
   
   This is obviously possible and should be checked. However, I rather doubt the contest was meant to involve such nastinesses.
2. The second is more interesting. We're going to assume that births are a uniform random process.
   
   To never have a prime birthday, your birthday must either be even or divisible by five. That leaves odd days but not multiples of five.
   • Thirty one day months have 13 possible prime days, so 18 never prime ones.
   • Thirty day months have 12 possible prime days, so 18 never prime ones.
   • Twenty nine day months also have 12 possible prime days, but 17 never prime ones.
   • Twenty eight day months have 11 possible prime days and 17 never prime ones.
     
   
   That the latter two are equal means we don't need to take as much case over leap years. There are 7 * 18 + 4 * 18 + 1 * 17 = 11 * 18 + 17 = 215 never prime days in a year.
   
   So, ignoring leap years the percentage is 215 / 365 * 100 = 58.9%.
   Leap years are 58.7%.
   
   Rather than fiddling around with the four, one hundred and four hundred year cycles, I'll round it up to 59%
   
   Baring some arithmetic errors on my part.
3. I've an idea on how to approach this -- look at deltas between dates and prove that either December 31st or January 1st must be divisible by three. The four years would hint that leap years are involved and 366 is divisible by three.
   
   

[Paul Dale]

This is thread 666 in the General Forum. Not that that means anything significant at all.

- Pauli

[Paul Dale]

(09-24-2014 09:31 AM)Paul Dale Wrote:  I've an idea on how to approach this -- look at deltas between dates and prove that either December 31st or January 1st must be divisible by three. The four years would hint that leap years are involved and 366 is divisible by three.

Would the absence of a leap year around three out of four centuries make a difference here I wonder?


- Pauli

[David Hayden]

An odd number of PDPs happen in pairs when 12/31 and 1/1 are prime, but only when the next New Year isn't also prime. Assume there is a 4 year range. Call the number representing the year before this range X. Now compute the offsets K1, K2, etc. to the supposedly prime days. Take the offsets mod 3 and you find that at least one is 0, 1, or 2. That means that regardless of what X mod 3 is, (X + Kn) mod 3 will be zero for at least one of the Kn's.

[Paul Dale]

Just ignore this post. It is completely misguided and wrong

- Pauli

(09-24-2014 09:41 AM)Paul Dale Wrote:  Would the absence of a leap year around three out of four centuries make a difference here I wonder?

Turns out it doesn't.

Odd numbers of PDP dates can only occur when one of January 1st or December 31st is prime. This means that a sequence of such years requires December 31st of one and January 1st of the next to be prime and a skip until December 31st of the subsequent year. Starting with January 1st instead of December 31st doesn't help because for January 1st to be PDP, the previous December 31st must be too.

1. December 31st prime, assume without loss of generality that it is congruent to 1 mod 3
2. January 1st (1 day), congruent to 2 mod 3
3. December 31st (729 days), congruent to 2 mod 3
4. January 1st (1 day), congruent to 0 mod 3, cannot be prime.
   

Put a leap year in the second or third year (a leap year in the first doesn't matter):

1. December 31st prime, assume it is congruent to 1 mod 3
2. January 1st (1 day), congruent to 2 mod 3
3. December 31st (730 days), congruent to 0 mod 3, cannot be prime.
   

The lengths of time and their modulo 3 outcomes are:

Code:

    Interval      mod 3
    1 day           1  
    729 days        0  
    730 days        1

- Pauli

[David Hayden]

(09-24-2014 11:46 AM)Paul Dale Wrote:  

1. December 31st prime, assume without loss of generality that it is congruent to 1 mod 3
2. January 1st (1 day), congruent to 2 mod 3
3. December 31st (729 days), congruent to 2 mod 3
4. January 1st (1 day), congruent to 0 mod 3, cannot be prime.
   

You're counting days instead of the difference in the YYYYDDMM representation. The difference between December 31 of one year and the next is 10,000, not 729. E.g. 20141231 - 20131231.

(09-24-2014 11:46 AM)Paul Dale Wrote:  Put a leap year in the second or third year (a leap year in the first doesn't matter):

Leap years don't matter since we aren't counting days.

This changes the details of your analysis, but the results are the same: one of the days must be divisble by 3.

(09-24-2014 11:46 AM)Paul Dale Wrote:  Starting with January 1st instead of December 31st doesn't help because for January 1st to be PDP, the previous December 31st must be too.

I think it can work:

1. Jan 1.
2. Dec 31.
3. Jan 1
4. Dec 31
   

You have to include years 0 and 5 in the analysis of this pattern but you get the same result: one of the days that must be prime can't be prime.

[Dave Britten]

Eagerly awaiting Don's mind-flaying 17BII solver solution.

Might try this on my 48 GX and/or SX later if I need to kill an hour or two.

[Don Shepherd]

(09-24-2014 01:39 PM)Dave Britten Wrote:  Eagerly awaiting Don's mind-flaying 17BII solver solution.

It is an interesting problem. Since the solver has no prime finder and the 17b is not a fast machine, it may take some time, but it should be possible. One would have to output the dates one at a time, of course, given how the solver works.

I'll have to think about this one.

[Joe Horn]

(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.

This is obviously possible and should be checked. However, I rather doubt the contest was meant to involve such nastinesses.

Yes, the Programming Contest used the current Gregorian calendar system for the entire year range specified (1583-9999). Reason: that's what most (all?) HP calculators do. I should have been specific about that in the contest rules, but thankfully the contestants all assumed it too. The only reason that I did not start at 15 Oct 1582 (like HP does) is because that would require special handling for that one year, and that would be more annoying than fun. And it's a good bet that the Gregorian calendar system will be abandoned long before 9999 rolls around... but I used the whole range because I used 7968 as one of the test cases (it has Feb 29, Mar 1, Mar 31, and Apr 1 as PDPs).

[Paul Dale]

(09-24-2014 12:46 PM)David Hayden Wrote:  You're counting days instead of the difference in the YYYYDDMM representation.

Bummer I screwed up in a big way

Thanks for the correction.


Pauli

[David Hayden]

(09-24-2014 03:18 PM)Joe Horn Wrote:  thankfully the contestants all assumed it too.

Not me. The first thing I did was look up when the calendar changed. I was glad that you were merciful on us....

[Paul Dale]

(09-25-2014 12:48 AM)David Hayden Wrote:  The first thing I did was look up when the calendar changed. I was glad that you were merciful on us....

This depends a lot on where you are. E.g. Greece changed very very late. Sweden started changing gradually (they had Feb 30th e.g.), decided not to and went back and then changed later.


- Pauli

[brouhaha]

Of the conference attendees who submitted RPN (not RPL) entries to the programming contest, my entry for the WP 34s was the worst. I don't really have that much 34s experience, so I worked on it until about 4:30 AM Sunday morning. Had I known about SDL, SDR, and RTN+1, that would have shaved off quite a few steps. I avoided a few optimizations due to the contest rules favoring elegance over trickiness. Here's the writeup I gave Joe when I submitted the entry:

Code:

HHC 2014 Programming Contest Entry
Eric Smith
For WP 34S

The output format is YYYYMMDD.

All output is done by PSE 10 (approx 1.0 sec).

NOTE: contents of X register when program terminates is not
considered an output.  It will by January 1 of the following
year, in YYYYMMDD format, regardless of whether it is prime.

Two flags are used to handle boundary conditions:
flag 01 clear when handling first month (DEC 31 of prev year, JAN 01 of specified year),
        set for all subsequent months
flag 02 set when handling thirteenth month (DEC 31 of specified year, JAN 01 of next year)

No storage registers are used.  Whether that is elegant or inelegant may be debatable.

A "SKIP 1" is used at one point after a test instruction.  Normally I would consider a
SKIP instruction inelegant, since it is an impediment to program understanding and editing.
However, a "SKIP 1" after a test instruction effectively acts as an inversion of the test,
which in my opinion is elegant.

The constant 8800 is used.  A line could be saved by coding it as "CONST #088, CONST #100, *",
but this seems inelegant.  Using another factorization such as "CONST #176, CONST #050, *"
might be even worse since that further obfuscates the value.

In comments in the listing below, mm is month, mp is previous month


01 * LBL "A"
02   MODE Y.MD
03   CFALL                                    ; init boundary condition flags

04   CONST #013                               ; init month counter
05   x<>y

06   E                ; 1 yyyy cnt
07   4                ; 1E4 yyyy cnt
08   *                ; yyyy0000 cnt
09   INC .X           ; yyyy0001 cnt
10   GTO 02
                                    
11 * LBL 01           ; yyyymm01 cnt          ; main loop
12   SF 01                                    ; mark already handled JAN 01
13   FS? 02                                   ; already handled DEC 31?
14   RTN                                      ; yes

15 * LBL 02
16   CONST #100       ; 100 yyyymm01 cnt      ; advance to next month
17   +                ; yyyymm01 cnt

18   DSZ .Y           ; yyyymm01 cnt-1        ; reached 13th month?
19   GTO 03                                   ; no, go process

20   SF 02            ;                       ; flag final month
21   8                ; 8 yyyy1301 cnt-1      ; adjust from 13th month to first month of next year
22   8                ; 88 yyyy1301 cnt-1
23   0                ; 88 yyyy1301 cnt-1
24   0                ; 8800 yyyy1301 cnt-1
25   +                ; yyyz0101 cnt-1

26 * LBL 03
27   PRIME?           ; yyyymm01 cnt          ; day 01 of month prime?
28   SKIP 1           ; yyyymm01 cnt          ; yes - SKIP 1 after test reverses sense of test
29   GTO 01           ; yyyymm01              ; no, try next month

30   RCL X            ; yyyymm01 yyyymm01 cnt ; save as potential second day of pair

                                              ; back up to last day of prev month
31   E                ; 1 yyyymm01 yyyymm01 cnt
32   4                ; 1E4 yyyymm01 yyyymm01 cnt
33   /                ; yyyy.mmdd yyyymm01 cnt
34   1                ; 1 yyyy.mmdd yyyymm01 cnt
35   CHS              ; -1 yyyy.mmdd yyyymm01 cnt
36   DAYS+            ; yyyy.mpdd yyyymm01 cnt
37   E                ; 1 yyyy.mpdd yyyymm01 cnt
38   4                ; 1E4 yyyy.mpdd yyyymm01 cnt
39   *                ; yyyympdd yyyymm01 cnt

40   PRIME?             
41   GTO 04                                   ; yes, found a pair
42   RDN              ; yyyymm01 cnt          ; no, get potential second day back
43   GTO 01                                   ; try next month

44 * LBL 04                                   ; first day of month and last day of prev month both prime
45   FS? 01           ; yyyympdd yyyymm01 cnt ; was first day Jan 1?
46   PSE 10           ; yyyympdd yyyymm01 cnt ; no, so display prev date
47   RDN              ; yyyymm01 cnt
48   FC? 02                                   ; handling DEC 31?
49   PSE 10                                   
50   GTO 01                                   ; try next month

When I finished that at 4:30 AM, I decided to have a go at an RPL version. I was convinced that I wouldn't even be in the running for RPL, and I was very tired and wanted to get some sleep before the start of the Sunday session, so I only spent half an hour on it, and didn't do even some obvious optimizations, such as replacing "3 ROLL" (which had earlier in the development been "4 ROLL") with ROT. With the benefit of hindsight, I should have stopped optimizing my 34s program around midnight and spend more time optimizing my RPL entry. My RPL entry as submitted was apparently the same length as David Hayden's winning entry as submitted. My writeup (done "by hand", so direct ASCII import to an RPL calculator will fail):

Code:

HHC 2014 Programming Contest Entry
Eric Smith
For HP 50g

The output format is YYYYMMDD.  The output will be a list left on the stack.

306.5 #2586h
<< { } SWAP                      ; yyyy {}
   1E4 *
   1 +                           ; yyyy0001 {}
   0 12 FOR i
     100 +                       ; yyyymm01 {}
     IF i 12 == THEN
       8800 +
     END
     DUP                         ; yyyymm01 yyyymm01 {}
         10000 /                            ; yyyy.mmdd
         DUP IP 1e6 /                       ; .00yyyy yyyy.mmdd
         SWAP FP 100 *                      ; mm.dd .00yyyy
         +                                  ; mm.ddyyyy
         -1 DATE+                           ; mm.ddyyyy
         100 *                              ; mmdd.yyyy
         DUP IP                             ; mmdd mmdd.yyyy
         SWAP FP                            ; .yyyy mmdd
         1e8 *                              ; yyyy0000 mmdd
         +                                  ; yyyymmdd
                                 ; yyyympdd yyyymm01 {}
       IF DUP2 ISPRIME? SWAP ISPRIME? AND THEN
         IF i 0 /= THEN
                                 ; yyyympdd yyyymm01 {}
           3 ROLL                ; {} yyyymmdd yyyymm01
           SWAP +                ; {} yyyymm01
           SWAP                  ; yyyymm01 {}
         ELSE
           DROP                  ; yyyymm01 {}
         END
         IF i 12 /= THEN
           DUP                   ; yyyymm01 yyyymm01 {}
           3 ROLL                ; {} yyyymm01 yyyymm01
           SWAP +                ; {} yyyymm01
           SWAP                  ; yyyymm01 {}
         END
       ELSE
         DROP
       END

   NEXT                          ; yyyymm01 {}
   DROP                          ; {}
>>

The final DROP is not strictly necessary, since the contest rules didn't
say that we couldn't leave extra junk on the stack.  For that matter, the
program would be slightly shorter if we just left the answers on the stack
indivdually, but if we didn't also include a count that would be rather
unfriendly.

Thanks to Joe for yet another interesting programming challenge!

[Paul Dale]

(09-25-2014 06:12 AM)brouhaha Wrote:  Of the conference attendees who submitted RPN (not RPL) entries to the programming contest, my entry for the WP 34s was the worst.

Trimming labels etc saves at least a dozen steps. This is then shorter than mine.

I hadn't thought of using SKIP 001 to invert a conditional -- for almost all conditionals we've got the inverse there already. PRIME? is one of the exceptions. I've used things like this trick before on less well featured calculators.


- Pauli

[Neil Hamilton]

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...

I realized that I could increment by 2 if the first candidate was odd, unless the day of the month was in danger of rolling over to a new month, so pegged this limit at > 27 to make February happy. This got it down to 60 s/yr.

Cleaned up a bunch of duplication and it dropped to 23 s/yr. Getting better.

Then I realized that the ONLY PDPs occurred when the months changed over (eg: 31 Mar - 1 Apr). So I only needed to make 7 (+1) sets of tests per year on the 31st of one month and the 1st of the next, and adding in poor February by subtracting 1 from 1 Mar to see if it is a leap year or not. The months were encoded into a list {1 3 5 7 8 10 12} and this list was processed using FOR and GET with dates being synthesized from the entered year, the day of 31 and the month extracted from the list, and then used searched for PDPs. The February issue was executed after the main list processing loop so PDPs found here could be displayed out of sequence. This got me down to just under 1 s/yr such that I ran the set of years from 1593 - 2014 in 430 s (432 yrs) which detected 58 PDPs. Running from 1800 - 2014 I got 14 PDPs in 113.3 s.

I will run 1583 - 9999 at work on my 50G plugged into USB so I don't destroy my batteries. I estimate that will take ~8400 s and should yields about 1122 +/- 50 PDPs.

The program is still a bit large at 401.5 bytes but I can likely drop it some. I am currently printing out more that the required minimum, for example.

Has the definitive list of PDPs been released?

Was there a ruling on a PDP anchoured to 31 Dec spilling into 1 Jan of the next year (cannot recall if I found any)? Technically that would not be in a single calendar year: "(and only in that year)".

(Pauli, my eldest is haunting Brisbane for the next week or so. For someone who is nervous of heights, he did the Sydney Bridge walk. Not something I would choose to do.)

Cheers...

[Don Shepherd]

(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...

I realized that I could increment by 2 if the first candidate was odd, unless the day of the month was in danger of rolling over to a new month, so pegged this limit at > 27 to make February happy. This got it down to 60 s/yr.

Cleaned up a bunch of duplication and it dropped to 23 s/yr. Getting better.

Then I realized that the ONLY PDPs occurred when the months changed over (eg: 31 Mar - 1 Apr). So I only needed to make 7 (+1) sets of tests per year on the 31st of one month and the 1st of the next, and adding in poor February by subtracting 1 from 1 Mar to see if it is a leap year or not. The months were encoded into a list {1 3 5 7 8 10 12} and this list was processed using FOR and GET with dates being synthesized from the entered year, the day of 31 and the month extracted from the list, and then used searched for PDPs. The February issue was executed after the main list processing loop so PDPs found here could be displayed out of sequence. This got me down to just under 1 s/yr such that I ran the set of years from 1593 - 2014 in 430 s (432 yrs) which detected 58 PDPs. Running from 1800 - 2014 I got 14 PDPs in 113.3 s.

I will run 1583 - 9999 at work on my 50G plugged into USB so I don't destroy my batteries. I estimate that will take ~8400 s and should yields about 1122 +/- 50 PDPs.

The program is still a bit large at 401.5 bytes but I can likely drop it some. I am currently printing out more that the required minimum, for example.

Has the definitive list of PDPs been released?

Was there a ruling on a PDP anchoured to 31 Dec spilling into 1 Jan of the next year (cannot recall if I found any)? Technically that would not be in a single calendar year: "(and only in that year)".

(Pauli, my eldest is haunting Brisbane for the next week or so. For someone who is nervous of heights, he did the Sydney Bridge walk. Not something I would choose to do.)

Cheers...

Neil, I thought the problem included only generating the list of PDPs for a specific given year: you input a year, and the program tells you the PDPs for that year (max of 7, of course). So the length of time the program runs is governed largely by the routine to determine if a number is prime. If that takes 10 seconds for a given number, for example, then the whole program (7 iterations max) would take less than 70 seconds since the factors of several of those numbers would be found rather quickly.

[Neil Hamilton]

The main program executes for a single year - thougn it does have that 'bug' of including the 1 Jan date from the next year. I have another shell that executes a range of years by repeatedly calling the main program. It is that one that I pulled the run times from in order to provide a good average.

Is that what you meant?

[Don Shepherd]

(09-27-2014 06:56 PM)Neil Hamilton Wrote:  The main program executes for a single year - thougn it does have that 'bug' of including the 1 Jan date from the next year. I have another shell that executes a range of years by repeatedly calling the main program. It is that one that I pulled the run times from in order to provide a good average.

Is that what you meant?

I guess I was confused, when you said 23 secs per year I wondered why you were running multiple years, but I think I see what you mean.

I would say Dec 31 to Jan 1 of the following year is out-of-scope and should not be tested.

thx, Don

[Joe Horn]

(09-27-2014 04:47 PM)Neil Hamilton Wrote:  Has the definitive list of PDPs been released?

Not until now. Here 'tis, generated by a UBASIC program.

Complete List of Prime Date Pairs in the Gregorian Calendar from
1583 through 9999. The final section below (December/January)
shows both (paired) years; the first is for December and the second
is for the following January.

Jan/Feb:

1613 1679 1769 1787 1793 1835 1925 1979 2075 2138 2165 2171 2264 2291
2330 2372 2420 2438 2456 2576 2600 2633 2765 2876 2885 2900 2933 2987
3047 3068 3083 3155 3221 3317 3515 3614 3827 3914 3923 3929 3944 4202
4220 4271 4328 4352 4409 4415 4490 4538 4781 4790 4871 4979 5000 5015
5096 5108 5129 5132 5153 5273 5306 5327 5375 5378 5441 5480 5531 5570
5582 5693 5738 5840 5909 5990 6050 6197 6200 6203 6299 6314 6317 6320
6761 6851 6863 6884 6893 7022 7175 7223 7274 7289 7373 7457 7523 7610
7790 7799 7826 7832 7979 7982 8024 8105 8198 8408 8528 8534 8540 8594
8657 8660 8750 8765 8807 8813 9005 9014 9035 9068 9122 9155 9218 9275
9344 9431 9575 9662 9701 9731 9770 9773 9812 9830 9851 9968

Feb/Mar:

1636 1924 2028 2080 2304 2308 2448 2508 3036 3124 3264 3424 3688 3748
3816 3820 3904 4464 4936 5004 5020 5116 5196 5244 5560 5616 5652 5680
6124 6396 6408 6436 6460 6760 7008 7248 7692 7744 7968 8052 8520 8892
8968 9532 9696

Mar/Apr:

1608 1629 1632 1674 1764 1824 1866 1881 1950 1983 2064 2136 2211 2262
2289 2385 2511 2535 2574 2634 2706 2781 2802 2814 2829 2847 2850 2940
3000 3039 3072 3114 3171 3186 3210 3252 3267 3285 3297 3327 3351 3441
3480 3546 3564 3591 3633 3648 3747 3822 3855 3894 4323 4365 4383 4449
4467 4491 4629 4650 4695 4701 4722 4752 4779 4803 4836 4881 4914 4935
4950 4992 5067 5082 5229 5298 5469 5541 5580 5613 5619 5643 5655 5658
5709 5721 5745 5823 5850 5919 5955 5976 6042 6099 6153 6201 6255 6270
6273 7770 7803 7806 7884 7950 7968 8049 8055 8127 8154 8220 8262 8280
8283 8478 8490 8589 8694 8769 8862 8967 8985 9000 9009 9204 9249 9330
9435 9447 9519 9693 9750 9765 9780 9843 9864 9876

May/Jun:

1732 1804 1870 1876 1921 2002 2080 2110 2122 2257 2338 2425 2485 2539
2542 2674 2680 2713 2731 2737 2818 2884 2944 3085 3226 3274 3289 3388
3472 3511 3598 3787 3862 3868 3877 3928 4084 4123 4150 4225 4231 4396
4411 4417 4456 4480 4528 4585 4663 4669 4693 4726 4807 4816 4834 4873
4876 4948 4999 5041 5110 5302 5338 5359 5389 5425 5461 5512 5635 5776
5785 5956 5968 6073 6082 6103 6112 6118 6181 6196 6283 6301 6328 6397
6475 6532 6541 6607 6664 6679 6730 6754 6853 6937 6979 7039 7063 7108
7111 7120 7153 7183 7222 7354 7384 7585 7624 7672 7789 7837 7888 7966
8008 8041 8086 8131 8212 8233 8257 8317 8470 8497 8503 8560 8578 8581
8659 8743 8758 8866 8935 8977 9139 9328 9370 9373 9415 9559 9577 9637
9694 9832 9868 9889 9913 9997

Jul/Aug:

1664 1679 1697 1706 1796 1841 1847 1886 1913 2018 2093 2204 2282 2315
2396 2435 2540 2561 2615 2777 2798 2912 2951 3014 3122 3131 3155 3176
3212 3260 3266 3278 3344 3377 3398 3521 3554 3572 3611 3653 3692 3710
3755 3758 3800 3818 3875 3887 3920 4007 4064 4073 4118 4157 4181 4253
4298 4310 4349 4364 4388 4643 4685 4871 5039 5093 5144 5255 5276 5294
5399 5483 5603 5642 5735 5897 5915 5996 6092 6113 6125 6158 6167 6251
6257 6275 6458 6479 6599 6704 6710 6731 6803 6806 6839 6878 6920 6929
6983 7007 7100 7124 7187 7217 7223 7241 7391 7496 7538 7601 7730 7733
7766 7859 7892 8039 8060 8195 8204 8207 8288 8294 8297 8309 8327 8375
8435 8507 8594 8606 8621 8642 8675 8783 8819 8906 8909 8936 9179 9194
9263 9326 9467 9482 9536 9833 9872 9956 9959

Aug/Sep:

1588 1672 1678 1990 2017 2068 2107 2242 2281 2290 2302 2320 2374 2404
2413 2446 2539 2611 2614 2617 2728 2926 3079 3109 3190 3223 3274 3328
3346 3430 3439 3475 3508 3640 3661 3670 3853 3886 3901 4024 4135 4171
4210 4231 4459 4486 4525 4528 4567 4630 4732 4765 4912 4915 4927 4996
5068 5080 5158 5161 5239 5272 5371 5455 5473 5524 5584 5614 5650 5764
5839 5887 5992 5998 6058 6064 6208 6226 6235 6280 6343 6394 6424 6526
6547 6631 6742 6823 6838 6895 6904 7330 7363 7450 7483 7519 7555 7561
7612 7663 7717 7720 7768 8029 8038 8065 8149 8164 8191 8272 8287 8344
8455 8494 8545 8599 8665 8881 8884 8905 8932 9082 9094 9145 9301 9310
9313 9397 9451 9490 9547 9625 9658 9700 9760 9838 9841 9925

Oct/Nov:

1586 1652 1679 1709 1733 1793 1805 1811 1997 2036 2081 2132 2150 2216
2312 2414 2420 2435 2444 2510 2531 2570 2660 2729 2801 2834 2864 2867
2912 2927 2945 2990 3107 3173 3395 3407 3428 3470 3575 3632 3800 3857
3896 3899 3932 3995 4016 4088 4181 4262 4334 4340 4394 4400 4445 4478
4484 4559 4571 4580 4598 4769 4793 4796 4802 4874 4925 4934 5003 5039
5045 5150 5396 5429 5486 5537 5588 5618 5681 5726 5768 5804 5930 6089
6167 6242 6281 6326 6353 6446 6452 6530 6644 6656 6899 6914 6917 6953
7001 7058 7118 7130 7139 7151 7169 7247 7253 7268 7343 7370 7421 7436
7454 7466 7475 7529 7562 7610 7742 7988 8012 8030 8210 8321 8324 8327
8384 8483 8573 8750 8789 8819 8948 8978 9092 9137 9146 9290 9323 9392
9395 9431 9464 9548 9566 9884

Dec/Jan:

1600 1601 1621 1622 1747 1748 1810 1811 1828 1829 1891 1892 1930 1931
1972 1973 1978 1979 1987 1988 2020 2021 2029 2030 2161 2162 2383 2384
2413 2414 2437 2438 2533 2534 2581 2582 2602 2603 2650 2651 2689 2690
2776 2777 2932 2933 3097 3098 3298 3299 3379 3380 3487 3488 3538 3539
3574 3575 3634 3635 3685 3686 3688 3689 3694 3695 3727 3728 4000 4001
4099 4100 4141 4142 4162 4163 4189 4190 4240 4241 4246 4247 4252 4253
4306 4307 4411 4412 4597 4598 4642 4643 4684 4685 4756 4757 4813 4814
4990 4991 4996 4997 5029 5030 5053 5054 5104 5105 5326 5327 5374 5375
5428 5429 5437 5438 5542 5543 5557 5558 5647 5648 5659 5660 5716 5717
5788 5789 5818 5819 5848 5849 5953 5954 6103 6104 6184 6185 6196 6197
6208 6209 6235 6236 6259 6260 6298 6299 6532 6533 6544 6545 6613 6614
6655 6656 6688 6689 6763 6764 6814 6815 6859 6860 6892 6893 6940 6941
7003 7004 7090 7091 7102 7103 7249 7250 7258 7259 7291 7292 7297 7298
7405 7406 7552 7553 7570 7571 7633 7634 7663 7664 7684 7685 7699 7700
7858 7859 7897 7898 7936 7937 7957 7958 8041 8042 8110 8111 8194 8195
8233 8234 8440 8441 8446 8447 8455 8456 8503 8504 8587 8588 8611 8612
8653 8654 8656 8657 8686 8687 8755 8756 8875 8876 8989 8990 9001 9002
9031 9032 9244 9245 9304 9305 9313 9314 9547 9548 9673 9674 9766 9767
9817 9818 9850 9851 9976 9977

(09-27-2014 04:47 PM)Neil Hamilton Wrote:  Was there a ruling on a PDP anchoured to 31 Dec spilling into 1 Jan of the next year (cannot recall if I found any)? Technically that would not be in a single calendar year: "(and only in that year)".

It happens a lot (see last section in the table above). The contest rules limited output to only the PDP dates in the input year, so there CAN be an odd number of PDP dates in one year. Several contestants told me that this fact didn't dawn on them until they read the "Homework Problems" on page 2. All the contest entries handled all the test cases correctly.