[HN Gopher] Optimizing with Novel Calendrical Algorithms
___________________________________________________________________
Optimizing with Novel Calendrical Algorithms
Author : jhpratt
Score : 7 points
Date : 2025-02-03 07:06 UTC (15 hours ago)
(HTM) web link (jhpratt.dev)
(TXT) w3m dump (jhpratt.dev)
| weinzierl wrote:
| Why does the number of Total Cycles _increase_ for the faster
| version?
| mmastrac wrote:
| There is a preliminary version with more -- but the final
| version has fewer cycles
| zokier wrote:
| It is still bit odd considering tha in the actual benchmarks
| the preliminary version is significantly faster than the old
| one. So there seems to be fairly large discrepancy between
| the cycles estimation and actual runtime
| picafrost wrote:
| This is a great and very interesting write-up. It has never
| occurred to me that there might be algorithms applicable to
| calendars.
|
| It strikes me that the Gregorian calendar might encode some of
| the most calcified tech debt of humanity. It attempts to fit
| solar, lunar, and 7-day religious-oriented cycles (and who knows
| what else?) into one system. So many cultural and religious
| touchstones are oriented around the (month, day) tuple. For extra
| confusion add the asymmetry between cultures who place traditions
| on the lunar calendar. Let's not mention timezones. A big thanks
| to you keepers of time (libraries).
|
| Deciding that time began with Unix and that it should simply
| count forward seems rather sane by comparison.
| ratmice wrote:
| My favorite technical debt is the off-by-two naming of
| quintilis through december from when they added Jan and Feb to
| the beginning of the calendar...
| TeMPOraL wrote:
| Yup. And directly related to that, the absurdity of having
| the _second month_ be the one that has weird numbers of days
| and gets a regular extra day to keep the calendar in sync
| with Earth 's revolutions. Adding or removing a day from the
| end of the year is the _obvious_ choice, so why not do it
| there?
|
| Turns out, people who came up with the leap year weren't
| stupid - the extra day used to be tacked to the end of a
| year. But then the thing you mentioned happen, the calendar
| was rotated right (in the positional arithmetic sense) by
| two, and what used to be the last month of the year is now
| called February.
| ratmice wrote:
| Yeah, I never understood why they couldn't make it Dec-Feb-
| Jan with January at the end of the year so that Janus could
| still be the god of transitions, but I guess I'm no
| theologian so there is probably a reason.
| jkafjanvnfaf wrote:
| Nice writeup and algorithm. My first instinct would have been to
| take the lazy way out and just use a table with 365 entries (or
| 366, or both depending on the implementation), but this is a lot
| more elegant.
| hairtuq wrote:
| The article leaves out optimizing is_leap_year. Here is an
| interesting version that is correct (in the Proleptic Gregorian
| calendar) for 0 <= year <= 102499 and takes only 3 instructions:
| ((year * 1073750999) & 3221352463) <= 126976
|
| How this works is surprisingly complex, I am thinking of writing
| a whole blog post about it...
___________________________________________________________________
(page generated 2025-02-03 23:01 UTC)