Krugman, Taylor, and Maclaurin

In this morning’s blog/newsletter,1 Paul Krugman included a couple of unusual graphs that I want to talk about. It took me a little while—longer than it should have—to figure out what he was doing and why, and I’m still not sure I agree with his plotting choices. Let’s go through them and you can decide for yourselves.

The two graphs of interest are made the same way, so we’ll focus on the first one. He introduces it this way:

The closest parallel I know to the Hormuz crisis is the oil shock that followed the 1973 Yom Kippur War. (The 1979 Iran crisis was more complex, involving a lot of speculative price changes.) World oil supply fell only moderately after 1973, but it had been on a rapidly rising trend until then, so there was a large shortfall relative to that trend. In the chart below I show the natural log of world oil consumption with 1965 as the base year:

And here’s the graph itself:

Krugman oil supply plot

Krugman usually apologizes in advance for the “wonky” parts of his posts, so I was surprised that he just breezed through the “natural log” and “base year” parts of his explanation. What he’s doing here is taking the oil consumption of a given year, dividing it by the consumption in 1965 (that’s the “base year” part), and then plotting the natural logarithm of that ratio against the year. The ratio for 1965 itself is, of course, one, which is why its log is zero.

Using logarithms to plot exponential growth is common because you end up with a straight line. What isn’t common is plotting the logarithm (natural or common) of the values on a linear scale, as Krugman does here. Plotting software typically (always?) offers you the option of plotting the actual values on a logarithmic scale. The advantage of taking that option is that although the ticks will be unevenly spread, the tick labels will represent those actual values, not their hard-to-interpret logarithms.

The interior of the plot would look the same if Krugman had used a log scale for the vertical axis. We’d still see the straight line showing exponential growth from 1965 through 1973, and then the very slight decay after that. The only difference would be the spacing and labeling of the horizontal grid lines.

So why did Krugman make the plot the way he did? I guess the answer lies in the paragraph after the plot:

The percentage difference between two numbers is approximately the difference in their natural logs times 100. So this chart shows that the world was burning approximately 17.5 percent less oil in 1975 than it would have under the pre-1973 trend — a supply shock not too different from what we will see now if the Strait remains closed.

The first sentence of this paragraph is what took me a while to understand. Then I remembered a Taylor series—actually a specialized Taylor series called a Maclaurin series—that I haven’t seen in quite a while.

Consider exponential growth at a yearly rate of α. After t years, the value, relative to starting value, will be

y=(1+α)t

(Note that α is expressed as a decimal value. If the yearly growth is 10%, α=0.10.)

Taking the natural log of both sides of this equation, and using the properties of logarithms and exponents, gives us

lny=ln[(1+α)t]=mt

where

m=ln(1+α)

(I should mention here that because I’m an engineer instead of a mathematician or programmer, I use ln for the natural logarithm instead of log. I use log for common [base 10] logarithms.)

This means that ln(1+α) is the slope of the exponential growth portion of Krugman’s plot.

This is where the series expansion comes into play. As I nearly forgot, we can express this logarithmic term as

ln(1+α)=αα22+α33α44+

and if α is small, the higher-order terms are very small, and

m=ln(1+α)α

so the growth rate (as a decimal) will be about equal to the slope of Krugman’s graph. To get the growth rate as a percentage, multiply by 100.

Is α small? Yes. For the eight-year period from 1965 to 1973, we see that the natural log of oil consumption goes up about 0.60. So the slope of that portion of the graph is

m=0.608=0.075α

which is pretty small.

The thing is, I’m pretty sure that whole “take the difference of the natural logs and multiply by 100” thing seemed like hand-waving to most of Krugman’s readers. If he’d just used a log scale on the vertical axis, he could’ve said that the lost oil consumption was about 17.5%, and it wouldn’t have seemed so magical because we’d all be able to see it in the graph.

Unless his purpose was to entertain people like me. In that case, good job!


  1. I’m pretty sure Krugman thinks of it as a newsletter because it’s hosted on Substack. I think of it as a blog because I read it through RSS. 


Keyboard Maestro launchers

During my seven-week Spotlight trial, I was reminded of how easy it is to make file and folder launchers in Keyboard Maestro. In case you’ve also forgotten, here’s a short post on how to do it.

There are three items that I open quite often and that Spotlight was slow to find:

The key to making a Keyboard Maestro macro to instantly launch a file or folder is the Open a File, Folder or Application action in the Open category. Here’s where you’ll find it in the Actions panel.

20260419-KM Open actions

The macros for opening the blog-stuff and calendrical folders in the Finder are one-step macros that look like this:

KM Blog-stuff folder

The path to the blog-stuff folder is

~/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff

The calendrical macro looks the same, except it uses the keyboard shortcut ⌃⌥⇧⌘C and opens

~/Library/Mobile Documents/com~apple~CloudDocs/programming/calendrical

(These keyboard shortcuts have the sort of complicated chording I’d never use if I weren’t running Karabiner Elements to turn Caps Lock into a “Hyper” key that mimics pressing ⌃⌥⇧⌘ simultaneously. If you read Brett Terpstra, you’ll recognize the Hyper key.)

The macro for opening the notebook index file is only slightly more complicated:

KM Notebook index

The path to the file is

~/Library/Mobile Documents/com~apple~CloudDocs/personal/Notebook index.txt

and the second step puts the cursor at the bottom of the file, which is usually where I want it, as I’m typically opening the index to add a new entry.

Even though I’m back with LaunchBar, and I can use it to get to these files and folders quickly, I’m keeping the macros. They’re not that much faster than ⌘-Space and typing a few characters, but they’re more accurate. There’s no risk of typing “cla” instead of “cal” when I want to open the calendrical folder.


Launchers and me

I started using launchers shortly after returning to the Mac (from Linux) in 2005. The first one I used was the great Quicksilver. I’m sure I learned about it from Merlin Mann, who was Quicksilver’s biggest advocate, but I can’t point to which of his many posts on QS got me started.

When Nicholas Jitkoff (Alcor) stopped developing Quicksilver in 2007 or so, I switched to LaunchBar, and that’s been my main launcher ever since.1 I gave Alfred a workout for a few months—inspired, I think, by this episode of Mac Power Users—and I’ve tried Spotlight a few times, but I’ve always returned to LaunchBar.

My most recent trial of Spotlight began in late February and ended yesterday. I’d been hearing about the new and improved Spotlight since the introduction of macOS 26/Tahoe, and this episode of Upgrade inspired me to give it another shot. You may recall that as the episode in which Jason and Myke reviewed the results of Jason’s annual Apple Report Card, and they talked about Spotlight as being one of Tahoe’s significant improvements.

So I turned off LaunchBar and began using Spotlight exclusively. It sucked. I hung on that long only because I kept thinking, “Surely it’s going to improve as it learns my habits.” It didn’t. It was unbearably slow when I started using it, and it was still unbearably slow when I finally decided to pull the plug on it yesterday.

How slow? Finding files and folders—even files and folders that I had been searching for and opening for a few days—typically took several seconds (yes, s…e…v…e…r…a…l seconds). Finding and launching apps with Spotlight was much faster, but even that had a noticeable delay. You may remember that Quicksilver was so-named because it was quick—so are LaunchBar and Alfred. Spotlight, despite being a system feature, is not.

So I’m back to LaunchBar. A new release came out during my Spotlight experiment, which was heartening, as I’ve been worried about LaunchBar’s continued viability as a product. I upgraded and reindexed my system (which took only a few seconds), and it feels like I’m back at my Mac again.

One last thing: If you feel compelled to tell me the Good News about Raycast, please restrain yourself. I know about Raycast, and I know that it seems like just the thing for someone who does as much scripting and automation as I do. And maybe it is. But it seems like a project I don’t want to take on right now. If I change my mind, I’ll let you know.

Update 18 Apr 2026 1:07 PM
It’s possible that Spotlight would work at a reasonable speed if I reindexed it. Myke Hurley has mentioned (not in the above-linked episode, but in others) that he’s needed to reindex Spotlight a couple of times. If that’s what I need to do to get it to work properly, count me out. Yes, I did reindex LaunchBar yesterday, but that was because it hadn’t run in seven weeks, and I wanted it up to date right away—I’ve never had to reindex it regularly.


  1. I’ve never tried the reconstituted Quicksilver. It may be fine, but I just don’t think it has enough momentum behind it. 


Easter in Mathematica

Yesterday’s post included some behind-the-scenes calculations that I figured were worth talking about. They were all done in Mathematica, and here’s the notebook I used:

The first calculation works out the days of the vernal equinox in every year from 1961 through 2026. The key function for this is FindAstroEvent, a fairly new function that returns the date and time of the first occurrence of a given event after the given date. I asked for the first MarchEquinox after January 1 of each year, and I wanted the time to be given in Greenwich Mean Time. Since I only cared about the day of the month, I used the DateList function to convert the DateObject returned by FindAstroEvent into a list of year, month, day, hour, minute, and second and pulled out just the third item of that list.

With equinoxes set to a list of 19s, 20s, and 21s, I used the Tally function to count the occurrences of each day number. As you can see, there were 58 20s in the list of 66 equinoxes, so I included that result in the post to show that March 20 is the most common date of the vernal equinox.

The remaining calculations were done to compare the algorithmic date of Easter with the date that Easter would be if it were determined by the actual date of the first full moon after the vernal equinox. So I used FindAstroEvent again, this time setting the event to FullMoon and the date to the equinox dates calculated earlier. That list of DateObjects was saved to the variable fullMoons.

I needed to compare these dates to the dates of Easter for the years of interest. Oddly, Mathematica doesn’t seem to have a built-in function for calculating Easter, but it does have a ResourceFunction. The function is called EasterSunday, and it calculates the date for the given year.

With the lists of easters and fullMoons in hand, I subtracted the latter from the former. If the difference is more than a week, the algorithmic and astronomical Easters aren’t in agreement. As you can see, there are two instances in which Easter is 31 days after the full moon: first in 1962 (which I didn’t mention in the post) and then again in 2019 (which I did). The final calculation was just a repeat of one of the calculations in equinoxes; I did it again so I wouldn’t have to hunt down the 2019 equinox date.

I’m not sure when I learned of the FindAstroEvent function, but it really came in handy yesterday. I’m pretty sure there are functions in Calendrical Calculations that deal with equinoxes and full moons, but I haven’t gotten that far in the book yet.