benjoffe

Thanks for sharing that.

I have a mobile-friendly web-app where you can practice this technique, just click the link in the page's nav: "Weekle - Weekday Guessing Game"

Thanks! I'm pretty sure with this one I spent more time working on the blog post than I did developing the algorithms.

I would not normally spend such effort, but in this case I felt that the functions were too hard to understand without the visual aid, and too difficult to customise without the Function Explorer.

Then I think I just got a bit carried away with the detail.

Correct URL: https://www.benjoffe.com/fast-leap-year

(The link in the submission is incorrect; apologies for the confusion.)

In this article I present a new faster full-range function to calculate whether a year is a leap year. This type of calculation is a fundamental date library utility, it is used all over the place: validating and parsing dates, determining the Nth last weekday of a month, handling month overflow/underflow when adjusting the day, etc.

The article outlines the technique, shows related developments before and after its creation, and includes an interactive, human-verifiable "proof".

That is an interesting question.

It might also come into play if developing SIMD alternatives for batch date processing, as one can have more lanes with 16-bit. I plan to make a blog post covering SIMD and if 16-bit algorithms have reasonable performance then that will be covered.

Thanks, that is a good idea. This was originally a blog post series, and the first article gave a bit of an introduction.

When I started the blog series, I expected the first article to be the most noteworthy, with the 2nd and 3rd being lesser supplementary topics.

Now that the 3rd blog post ended up with a much larger result than I was expecting, it stands on its own and could do with some editing as you suggest.

The first article in this blog post series has a little section talking briefly about this history, and there's a representation of this that I think sheds a lot of light on the original design. See the heading "Side-Note on Month / Day Determination" in the below link [1].

Displaying the months like the following helps see the regularity at a glance. Columns 1, 3 and 5 are the long months, others being shorter:

  +-----+-----+-----+-----+-----+
  | 31  | 30  | 31  | 30  | 31  |
  |  I  | II  | III | IV  |  V  |
  | MAR | APR | MAY | JUN | JUL |
  |-----+-----+-----+-----+-----+
  | 31  | 30  | 31  | 30  | 31  |
  | VI  |VII  |VIII | IX  |  X  |
  | AUG | SEP | OCT | NOV | DEC |
  +-----+-----+-----+-----+-----+
  | 31  |28/29|
  | XI  |XII  |
  | Jan | FEB |
  +-----+-----+

> To a person who natively thinks in Roman numerals, remembering that the short months are: II, VII, XII, along with IV & IX would be much easier than the way us modern folks have to memorise it.

[1] https://www.benjoffe.com/fast-date

Thanks.

I was fortunate enough to be programming on an ARM based device, which meant that the terms (x * 4 + 3) strongly stood out to me as highly inefficient, being 2 cycle prep for the more important division. On x64 computers, those two operations are calculated in only one operation by using the 'LEA' assembly instruction (which I wasn't aware of at the time), and so others using that type of computer might not have felt this step needed any simplification.

I tried everything under the sun to get rid of these steps. The technique noted in the article of using the year 101 BC was for a long time my strongest candidate, you can view the implementation of that attempt at the link below [1].

An epoch of 101 BC still meant that there was extra work required to re-normalise the timeline after the century calculation, but it was only a single addition of 365 in the calculation of `jul`. The explanation of how this works is probably a whole blog post in itself, but now that this algorithm has been discarded it's not worth the time to explain it fully.

I also had the year-modulus-bitshift technique developed at that time, but it couldn't be integrated cleanly with any of my algorithm attempts yet. My plan was to simply document it as an interesting but slower concept.

I don't know what sparked the idea of going backwards other than immersing myself deeply in the problem in my spare time for about a month. It finally came to me one evening, and I thought it was only going to save 1-cycle, but when it also meant the year-modulus-bitshift could be utilised, the entire thing fit together like a glove and the speed collapsed down from 20% time saving to 40%.

[1] https://github.com/benjoffe/fast-date-benchmarks/blob/218356...

A write-up of a new Gregorian date conversion algorithm.

It achieves a 30–40% speed improvement on x86-64 and ARM64 (Apple M4 Pro) by reversing the direction of the year count and reducing the operation count (4 multiplications instead of the usual 7+).

Paper-style explanation, benchmarks on multiple architectures, and full open-source C++ implementation.

This article dives deep into a topic I find very interesting, even if it’s not immediately useful.

If you don't have time to read, you may want to quickly check "Appendix A" for the “Smoitus” chart to see visually how the timezone alignment systems works, and "Section 5: Equation of Time (Smoital System)" to see how well this system tracks solar time.

As I noted in this HN post, I did not invent this system (there are other tutorials online). I'll update the web app itself to state this clearly.

The goal of the web app is more about the practice modes and daily game, people are free to use Doomsday for these if they like.

The initial popup dialogue shows the default locale setting with a "change" button right next to it, and it can be changed at any time on the settings tab.

The intention is to present dates the way they often are found in that country (not just the "gold standard"). From my understanding Canadians often encounter dates in all three formats you noted (although often using named months to avoid ambiguity).

All three date formats are used in Weekle when set to Canadian mode, and fully numeric d/m/y or m/d/y dates are only used if the date is >12 to avoid ambiguity.

Thanks. I like your suggestion and I'll add a YYYY-MM-DD only option.

Thanks, I'll add a dismiss button to that popout soon.

Thanks, there is some attempt in the code to auto select US/Canada date format if the user's timezone is in the USA or Canada, but I didn't actually test it to see if it is activated correctly. Any US user's able to chime in if it does?

Even if it works, I'll probably take your suggestion add a tip below the date to clarify the date format for the user's first session.

Thanks, that's a good point that it does not clearly explain the use of that table. I will update the page soon to explain that the table cell represents the last 2 digits of a year, and the left column is the result of the year calculation for that year. The table has only 28 years in it since any year 28 or higher can be simplified by subtracting 28, 56 or 84.

I recommend only attempting to memorise the table after you are already able to calculate the year number using the normal algorithm.

That's a good feature but quite different, if the user is at home when they need to use the app that first time then it reveals where the user lives and possibly personally identifies them.

It seems a bit extreme to offer apps one of two extremes: either my sub-metre location or no location at all. It seems the reasonable default for location sharing should be something like sharing the rough suburb that I'm in. This solves most use-cases such as showing closest store locations, delivery options, dating apps showing nearby matches, etc. It's only the occasional navigation app that needs to know exactly where the user is located.

> Is the 'light' reflecting off the asteroid emitted from the sun? I had never seen or even knew radar could distinguish value like what is shown here.

Yes it's emitted from the sun, it's clear given that the time-lapse shows "Inner moon eclipsed" when passing behind the site of the asteroid that is not lit.

Paradoxically, respecting the wishes of the dead is more about empowering the living. If there are no such guarantees then people alive will take actions to enforce their wishes past their death.

In the context of Wills, that would mean more people would transfer their estate before their death. In the context of Facebook, it would mean some people may delete certain data (or in some cases delete their entire account) if they don't want the data discovered after they die.

Which parts of the constitution do you think are bad?

Depends on the application of this, i.e. whether the total is more important or the individual values are more important.

Example: You're filling out a timesheet for a contracting job, and you worked 8 hours on several different tasks for your client, but your client's software rounds things to the nearest hour, then it would make sense to use an algorithm like this if your pay was going to be determined by this data entry. If your pay was not determined by this data entry then it may make sense to just round normally.

A lot of research in astronomy is conducted to figure out how bright certain objects are, one classic example is "Cepheid variable" stars, these pulsate at a rate correlating with their brightness.

You're right in that there is sometimes debate about whether the "standard candles" as they're referred to are as bright as we expect, see: https://en.wikipedia.org/wiki/Cosmic_distance_ladder#Problem...

He uses the following example for when to throw your own errors:

  var Controller = {
    addClass: function(element, className) {
      if (!element) {
        throw new Error("addClass: 1st argument missing.");
      }
      element.className += " " + className;
    }
  };

I don't think this is a very good as a native error will have all this information already in a stacktrace, and if you're running Chrome dev tools with 'Pause on exceptions' then you'll be shown the exact place this fails. Additionally, you need to now keep the function name in sync with the string (your IDE / build tool will not tell you if they get out of sync).

Better cases for custom errors are situations where a native error will not be thrown, such as:

- in his example method: if className is undefined

- valid objects in a state you don't expect

- switch statements that don't match any expected case

- etc.

It's believed that the spiral arms are quasi-static and that the stars move in and out of these regions of higher density.

See: https://en.wikipedia.org/wiki/Density_wave_theory

Not entirely sure, but could be using the data from the Orbiting Carbon Observatory satellite[0].

This satellite orbits the Earth on the order of ~16 times per day which would not be enough granularity for the smoothness of this video, so I assume it's been combined with other weather data and advanced modelling to provide the smooth interpolation.

[0] https://en.wikipedia.org/wiki/Orbiting_Carbon_Observatory

You can also use 'type assertions' to minimise restructuring, eg, the following is the same number of lines as your first example (and compiles to identical code):

    const a = A()
    a.b = new SubtypeOfB()
    (<SubtypeOfB> a.b).attributeOfSubtypeOfB = 123 //works

There are games of this sort, the earliest I'm aware of is this: https://en.wikipedia.org/wiki/The_Incredible_Machine_%28seri...

> It's very expensive, and more worryingly there are lots and lots of them available on the second hand market, almost new, at greatly reduced prices.

So why not get a second hand one?