4 ms·

This looks like an algorithm that could be useful if programmed rather than carried around in one's head. It also still requires a lookup to bootstrap it: the

This looks like an algorithm that could be useful if programmed rather than carried around in one's head. It also still requires a lookup to bootstrap it: the day-of-week of the last day of February for the selected year. So it's a clever and well-observed compilation of identified patterns, but not self-contained.

Areading314 7y ago
Did you read the whole thing?
- jimmyvalmer 7y ago
  No. As soon as the algo asserts "the last day of February is Thursday the 28th," and didn't explain how it knew 2019 wasn't a leap year or that the 28th was indeed a Thursday, I stopped reading.
  - aliceryhl 7y ago
    I think the idea behind this algorithm is that you have to remember one anchor date in the current year, and then you can find all other days in the same year.
    - Areading314 7y ago
      It later goes to explain a method to derive annual doomsdays based on a century-doomsday
ikeboy 7y ago
The version they have here is somewhat inefficient and not well presented. You can get from the year to the doomsday by a simpler formula: If odd, add 11; divide by 2; if odd, add 11. Count up to nearest multiple of 7 So e.g. 1955 turns into 66 turns into 33 turns into 44 turns into 5. Add that to 4 for the century (1900 is 4, 2000 is 3, that's all you really need to memorize) and you get 9, so the doomsday for 1955 is Monday. From there it's simple, 4/4 6/6 8/8 10/10 12/12, 9/5 7/11 per the mnemonic mentioned, last day of February, Jan 3/4 depending on leap year, and March 7 counting forward from February. There, that's the entire algorithm.
- kseistrup 7y ago
  To go from "any" century, you can also memorize "2053", which is the days in a 4-year cycle: 2000 = 2 = tuesday; 2100 = 0 = sunday; 2200 = 5 = friday; 2300 = 3 = wednesday. For years other than the centuries, we need to add an offset. Given the year CCXX, we have: (a, b) = divmod(XX, 12) c = b // 4 offset = a + b + c doomsday = start + offset E.g., for 2020 (XX == 20) we get: start = 2 # from the "2053" rule (a, b) = divmod(20, 12) # (1, 8) c = b // 4 # 2 offset = 1 + 8 + 2 = 4 (mod 7) doomsday = start + offset # 2 + 4 = 6 = saturday
  - ikeboy 7y ago
    The "add 11" trick in my comment is easier to remember and apply than dividing by 12 and taking remainders.
    - kseistrup 7y ago
      I guess we have different perceptions of which way is the easiest. There might even be methods we haven't heard about yet.
    - tzs 7y ago
      I like my current method [1], while only requires addition, doubling, and a couple of conditional increments or additions. Even if you don't bother doing any mod 7 reduction along the way, you never have to deal with a number above 32. With both divide by 12 and odd 11, I would find myself occasionally making a goof when dealing with years near the end of centuries. [1] https://news.ycombinator.com/item?id=21926543 https://news.ycombinator.com/item?id=21926543
elfexec 7y ago
> This looks like an algorithm that could be useful if programmed rather than carried around in one's head. It is. I remember this being one of my programming assignments in college. Another one is determining whether a year is a leap year.

Areading314 7y ago

Did you read the whole thing?

jimmyvalmer 7y ago
No. As soon as the algo asserts "the last day of February is Thursday the 28th," and didn't explain how it knew 2019 wasn't a leap year or that the 28th was indeed a Thursday, I stopped reading.
- aliceryhl 7y ago
  I think the idea behind this algorithm is that you have to remember one anchor date in the current year, and then you can find all other days in the same year.
  - Areading314 7y ago
    It later goes to explain a method to derive annual doomsdays based on a century-doomsday

ikeboy 7y ago

The version they have here is somewhat inefficient and not well presented. You can get from the year to the doomsday by a simpler formula: If odd, add 11; divide by 2; if odd, add 11. Count up to nearest multiple of 7 So e.g. 1955 turns into 66 turns into 33 turns into 44 turns into 5. Add that to 4 for the century (1900 is 4, 2000 is 3, that's all you really need to memorize) and you get 9, so the doomsday for 1955 is Monday. From there it's simple, 4/4 6/6 8/8 10/10 12/12, 9/5 7/11 per the mnemonic mentioned, last day of February, Jan 3/4 depending on leap year, and March 7 counting forward from February. There, that's the entire algorithm.

kseistrup 7y ago
To go from "any" century, you can also memorize "2053", which is the days in a 4-year cycle: 2000 = 2 = tuesday; 2100 = 0 = sunday; 2200 = 5 = friday; 2300 = 3 = wednesday. For years other than the centuries, we need to add an offset. Given the year CCXX, we have: (a, b) = divmod(XX, 12) c = b // 4 offset = a + b + c doomsday = start + offset E.g., for 2020 (XX == 20) we get: start = 2 # from the "2053" rule (a, b) = divmod(20, 12) # (1, 8) c = b // 4 # 2 offset = 1 + 8 + 2 = 4 (mod 7) doomsday = start + offset # 2 + 4 = 6 = saturday
- ikeboy 7y ago
  The "add 11" trick in my comment is easier to remember and apply than dividing by 12 and taking remainders.
  - kseistrup 7y ago
    I guess we have different perceptions of which way is the easiest. There might even be methods we haven't heard about yet.
  - tzs 7y ago
    I like my current method [1], while only requires addition, doubling, and a couple of conditional increments or additions. Even if you don't bother doing any mod 7 reduction along the way, you never have to deal with a number above 32. With both divide by 12 and odd 11, I would find myself occasionally making a goof when dealing with years near the end of centuries. [1] https://news.ycombinator.com/item?id=21926543 https://news.ycombinator.com/item?id=21926543

elfexec 7y ago

> This looks like an algorithm that could be useful if programmed rather than carried around in one's head. It is. I remember this being one of my programming assignments in college. Another one is determining whether a year is a leap year.