You’ve probably seen the stupid misspelling above Trump’s signature on the “morally binding” agreement that came out of the meeting.

Yes, he signed it as the “President of the Unites States” and then proudly posted it to Truth Social. I can’t imagine the agreement means anything, as you’d be hard-pressed to find a single moral shared among the people in the meeting. I will say, though, that Jensen Huang’s signature is pretty spiffy.

As for who was at the meeting, Trump also posted this seating chart, which hurts to look at:

Click the image to see it at full size, if you dare. Also, don’t feel obligated to follow either of the Truth Social links; I’m including them only because I feel an obligation to give credit—or in this case blame.

Lots of the images Trump posts are AI-generated, but I find it hard to believe that any AI system would produce something with this many graphical errors:

• The chairs on the left side of the table are vertically offset from those on the right side, even though there are the same number on each side. Poor Will Scharf is nearly off the end.
• The chairs on the left are distinctly farther from the table than the chairs on the right.
• The vertical spaces between chairs on a given side aren’t equal. The seats near the ends are closer to one another than the seats near the center.
• The two lines of chairs aren’t horizontally aligned. This was perhaps the smallest mistake, and you probably can’t see it unless you zoom in, but what drawing app wouldn’t automatically align the items?
• The names and chairs aren’t aligned vertically. You’d expect the names to be centered vertically with the chairs, and many of them are at least close to that, but once you see Alex Karp and Andrew Ferguson you’ll notice several similar misalignments.
• The names on the left side should be right-aligned but aren’t. Susie Wiles is way out of her chair, while David Sacks has nearly crashed into his.
• Similarly, the names on the right side should be left-aligned but aren’t. See Richard Walters and Sanjay Mehrotra for the most extreme misalignments.

And then there’s the best one:

• The chairs are facing away from the table.

The meeting probably would have been better for all of us if this had been so.

This short video appeared in my YouTube feed last week. It’s from Hannah Fry, whom you probably know from her appearances on Numberphile and other STEM-oriented stuff. If you’re in the UK, you’ve may have seen her on the BBC, too.

The short presents a classic problem in conditional probability, but the answer she comes up with is wrong. It’s a good estimate, and it’s the same answer I got when I stopped the video and tried to work it out in my head, but it’s still wrong. By just a little bit.

Here’s the problem: There’s a disease that affects 1 in 1,000 people. A test for the disease is perfect in one sense but imperfect in another. If you have the disease, the test will return a positive result 100% of the time. If you don’t have the disease, the test will return a negative result 95% of the time but a positive result 5% of the time. If you have the test and the result is positive, what is the probability you have the disease?

What makes this a classic problem is that it presents you with conditional probability in one sense (the probability of a positive test given that you have the disease) and asks for a conditional probability in the opposite sense (the probability that you have the disease given that your test was positive). The solution combines the definition of conditional probability, the commutative property of intersections, and the law of total probability.

Let’s define some events. $D$ is you having the disease, and $T$ is you getting a positive test result. Putting a horizontal bar over these indicates not having the disease and not testing positive (i.e., testing negative), respectively. Therefore

$$\begin{array}{cc}\hfill P(D)& =0.001\hfill \\ \hfill P(\stackrel{—}{D})& =0.999\hfill \\ \hfill P(T\mid D)& =1\hfill \\ \hfill P(\stackrel{—}{T}\mid \stackrel{—}{D})& =0.95\hfill \\ \hfill P(T\mid \stackrel{—}{D})& =0.05\hfill \end{array}$$

The vertical bars are read as “given,” meaning the event after the bar is the condition. What we’ve been asked to find is $P(D\mid T)$. Let’s work it out.

By the definition of conditional probability, we can say

$$P(D\cap T)=P(D\mid T)P(T)$$

where $\cap$ means the intersection of the two events. So

$$P(D\mid T)=\frac{P(D\cap T)}{P(T)}$$

Because the intersection of events is commutative

$$P(D\cap T)=P(T\cap D)=P(T\mid D)P(D)$$

Both terms on the right-hand side of this equation are known, so we can say

$$P(D\mid T)=\frac{(1)(0.001)}{P(T)}$$

Since $D$ and $\stackrel{—}{D}$ are mutually exclusive and collectively exhaustive, the law of total probability says

$$\begin{array}{cc}\hfill P(T)& =P(T\mid D)P(D)+P(T\mid \stackrel{—}{D})P(\stackrel{—}{D})\hfill \\ \hfill & =(1)(0.001)+(0.05)(0.999)\hfill \\ \hfill & =0.05095\hfill \end{array}$$

So

$$P(D\mid T)=\frac{0.001}{0.05095}=0.019627$$

which is, as I said, pretty close to the 2% answer in the video but not exactly.

This formal approach is how you’re taught to solve problems like this in an introductory probability class, but Dr. Fry and I used a more concrete method to get our nearly correct answers. Here’s what we did:

Imagine 1,000 typical people. Of these, 1 should have the disease (correct) and 50 should test positive (incorrect). That tells us that 1 in 50, or 2%, of the people who test positive will have the disease. Here’s a screenshot from the video that matches this calculation:

What makes this calculation wrong is that it implicitly assumes that 5% of everyone will test positive, not 5% of only those who don’t have the disease. The number who will test positive should be 5% of 999, which is 49.95, plus the 1 who does have the disease. So 1 in 50.95, or 1.9627%, of those who test positive will have the disease. This answer matches that of the formal approach.

This is somewhat unsatisfying, though, as the purpose of this “imagine a bunch of typical people” method is to have all the people counts be integers. Although the numbers work out when you get to the end, it’s distracting to litter the discussion with fractional people. You can get around this by imagining more people—a million, say—but then all the numbers get bigger: 1,000 people with the disease and 49,950 false positives. This isn’t a problem for the kind of people who read this blog but isn’t so great for the more general audience Dr. Fry is addressing.

Personally, I would have been OK with her saying that 5% of 999 is almost 50, so the number who test positive is nearly 51. And 1 out of 51 is just under 2%—call it 2% in round figures. You still make the point that it’s way less than 95% and that problems like this require some care.

That someone in the glorious Bartlet White House believes in nonsense isn’t what bothers me. Lots of smart people believe silly things. What’s wrong is that it’s C.J., the primary female character, who believes in superstition while the men around her are pooh-poohing it. I’m sure plenty of women will tell me that’s par for the course for Aaron Sorkin, but it still bothers me.

There are two small counters to the general sexism of the egg subplot. First, the men who tell C.J. she’s full of it are themselves wrong. They think you can’t balance an egg on its end, even though it’s not really that hard.

This photo was taken today (yes, on the equinox but not the vernal equinox and not at the exact moment) on my back patio. I didn’t do any tricks like slightly crack the shell or put it on a bit of salt and then blow the salt away. I just kept adjusting its position again and again until it stood. The plain fact is that it just takes a little time to balance an egg on its end, time that most people aren’t willing to spend. (And yes, it helps to have a rough surface.)

The second counter is that Jed seems willing to believe the egg story. He doesn’t defend C.J., but he does try to stand an egg on end in his office. In some ways, this is worse. For all his faults, Jed is supposed to know at least a bit about science. Remember the episode in which C.J. has to remind him to let the NASA experts handle the science questions coming in from schoolkids? If anyone should be instantly dismissive of the standing egg myth, it should be Jed.

At the very end of the show, C.J.’s alone and manages to balance an egg on its end, justifying her faith. The title comes from Hebrews 11:1, which she recites earlier in the episode. I guess this is supposed to get us to think that she hasn’t been spouting nonsense all this time, but what it really means is that she can do what anyone can do if they take their time.

What bothers me the most is the setup for her balancing act. Before trying, she looks pointedly at the clock, which shows midnight. Recall that the balancing is supposed to work only at the exact moment of the equinox. Does Sorkin think equinoxes always occur at midnight? Does he think the audience is dumb enough to believe that? The episode aired in April 2003, so I guess its events take place on March 20 of that year. In Washington, the 2003 vernal equinox occurred at about 8:00 pm, not four hours later. Was the show set a year or two earlier? No midnight spring equinoxes those years, either.

If you’re interested in the history of the egg balancing myth, Martin Gardner wrote an article about it in 1996. You can see the text on the Wayback Machine.

This video Matt Parker posted a couple of days ago really pissed me off:

It’s cheating to say that a result arrived at through classical mechanics—in this case, that $\frac{1}{2}m{v}^2$ is the kinetic energy of a particle—is wrong because it’s only an approximation to relativistic physics. Of course that’s the case, and I swore at my phone when the “reveal” came.

By the end of the video, though, I had calmed down because I knew I could put together a quick post of my own by rewriting the infinite series equation he derived in a better form. Also, I could provide a general expression for the individual terms.

Let’s start with this result: that the kinetic energy of a particle (including relativistic effects) is

$$m{c}^2(\gamma -1)$$

where m is the mass of the particle, c is the speed of light, and

$$\gamma =\frac{1}{\sqrt{1-\frac{v^2}{c^2}}}$$

is the Lorentz factor, with v as the velocity of the particle. The video gets to this result at about the 8-minute mark.

Matt then does a series expansion of the $\gamma$ term to get

$$\gamma =1+\frac{1}{2}\frac{v^2}{c^2}+\frac{3}{8}\frac{v^4}{c^4}+\frac{5}{16}\frac{v^6}{c^6}+\frac{35}{128}\frac{v^8}{c^8}+\dots$$

The leading 1 of this series gets canceled by the 1 that’s subtracted from γ, giving

$$\frac{1}{2}m{v}^2+\frac{3}{8}m\frac{v^4}{c^2}+\frac{5}{16}m\frac{v^6}{c^4}+\frac{35}{128}m\frac{v^8}{c^6}+\dots$$

for the kinetic energy. The leading term is the one we get from classical mechanics and the others are essentially zero unless you’re in a particle accelerator (which is discussed later in the video).

I don’t like this form for the equation. It’s cleaner if you factor out all the terms that give the expression the units of energy and then have a nondimensional expression afterward. Like this:

$$\frac{1}{2}m{v}^2(1+\frac{3}{4}\frac{v^2}{c^2}+\frac{5}{8}\frac{v^4}{c^4}+\frac{35}{64}\frac{v^6}{c^6}+\dots )$$

Isn’t this nicer? The expression in the parentheses is a function of the ratio of the velocity of the particle to the speed of light. If we call that

$$\varphi =\frac{v}{c}$$

then the kinetic energy is

$$\frac{1}{2}m{v}^2(1+\frac{3}{4}{\varphi }^2+\frac{5}{8}{\varphi }^4+\frac{35}{64}{\varphi }^6+\dots )$$

and it’s much easier to see why the terms after the 1 are vanishingly small for most situations—all the situations for which classical mechanics applies.

One last thing. Matt sort of explained how to calculate the terms of the expansion of γ in the companion video, but there was a lot of handwaving and he bailed out after the second term. It doesn’t take too much effort to show that the series expansion of γ can be written like this:

$$\gamma =\sum _{n=0,2,4,\dots }^{\infty }\frac{n!}{2^n{\left[\left(n/2\right)!\right]}^2}{\varphi }^n$$

That means the kinetic energy, $m{c}^2(\gamma -1)$, is

$$\frac{1}{2}m{v}^2\sum _{n=2,4,6,\dots }^{\infty }\frac{n!}{2^{n-1}{\left[\left(n/2\right)!\right]}^2}{\varphi }^{n-2}$$

You can confirm that these terms match the equation we saw earlier by plugging values of n from 2 through 8 into this expression. And now we can extend the series as far as we like, even though the additional terms add essentially nothing.

You can click on it to see a 300 dpi version. The Apple page linked above will give you infinite-resolution PDFs.

When I zoomed in on Stephen’s page, I was initially confused, but then I realized what seemed odd to me. You see, I’ve spent an awful lot of the past 40 years looking at engineering drawings, and I can’t think of any that looked like this. That’s because the drawings I’m used to are for making the depicted product, but the drawings Apple’s offering up here aren’t for that.¹ These are for others—not Apple and not its suppliers—to use for making cases and other accessories. I figured it was worth a quick post on what makes a drawing like the one above so different from what I’m used to.

First off, there are so many dimensions. Drawings of full products are typically called assembly drawings, and they have almost no dimensions. What they do is show how the various component pieces (subassemblies) are put together. The subassemblies have their own drawings that show how they are put together from their components, which are themselves typically subassemblies. Eventually, you get down to the individual part drawings, which depict a single piece of metal or glass or plastic. At each level in this hierarchy, the drawings tend to include only the dimensions necessary to build the object depicted. You don’t include the length and diameter of a screw on an assembly drawing; you simply call out its part number (which is also its drawing number).

Speaking of drawing numbers, if you look in the title block you’ll see that there is no drawing number. Design drawings always have these. They also have the names or initials of the draftsmen and checkers and, usually, a list of revisions. These public drawings don’t reveal any of that internal information.

There are names for many of the items and dimensions: product length, display active area, volume button, rear sensor, etc. These are not common in design drawings because they tend to be of no value to those doing the manufacturing. You don’t need to know what this hole is for; just make it this big and put it here.

Which leads us to tolerances, which are absent. Dimensions and positions are given to the nearest hundredth of a millimeter and there is no give or take. To the outside world, Apple’s dimensions are absolute and invariable. Inside Apple and its suppliers, people know better.

Also absent is any specification of material, other than a few generic mentions of glass. While assembly drawings don’t usually include materials, parts drawings always refer to material specs, usually included in another company document.

The last thing I’ll mention is the Notes section in the upper left corner. It has instructions clearly meant for people outside of Apple and making accessories. If I’d zoomed in on this section first, I probably wouldn’t have been even momentarily confused.

First came Live Rewind, a feature that lets you “go back in time” to pick up on something you missed that was said in the past 15 seconds. Here’s how Apple describes it on the website:

Live Rewind catches what you missed. Did someone say something you couldn’t hear in a loud restaurant or share cooking instructions you didn’t quite catch? Just double-click the Digital Crown, and Live Rewind transcribes what was said in the last 15 seconds. You can ask Siri about the content of the transcript or save it to the new Siri app to revisit later.

In the Event, this was illustrated by a waitress going through the restaurant’s specials too quickly for the diners to remember all of them. One of the diners double-clicks the crown on his watch and reads what she said.

It seems like your watch will be listening continuously, keeping the last 15 seconds in a buffer, ready to be transcribed when you ask. That’s fine for you, because you know it’s happening, but what about those around you? Did they agree to this? I doubt wait staff will be upset with their spiel being transcribed, but the idea behind Live Rewind seems to be that everyone and everything near your watch is being recorded for 15 seconds. Surely, some people wouldn’t consent to that if they were asked. Significantly, though, they’re not being asked. I’m sure Apple will argue that there’s no privacy issue because the recordings aren’t being saved. But if there’s a transcription, isn’t that a type of saving?

And then there’s the question of legality. A great variety of law, both in the United States and across the world, concerns the recording of electronic and in-person conversations. I’m sure Apple has considered this, but I have to think some jurisdictions will frown on Live Rewind. If Apple has to defend it, that’s fine. What’s one more squadron of lawyers to Apple? But if an Apple Watch owner has to defend a transcription made innocently—made with Apple’s encouragement, in fact—that seems like an unfair burden. Maybe Apple should indemnify all future Watch buyers from privacy-related legal action.

Right after Live Rewind, we get the introduction of Siri Recap. From the Series 12 web page:

Siri Recap can summarize your chats to refresh your memory. Siri Recap transforms your conversations into high-level notes, so you can stay focused and present. Each Siri Recap includes a title, a summary, and key points that you can review in the Siri app on your Apple Watch or iPhone. You can turn Siri Recap on or off at any time from Control Center or choose where and when it takes notes, such as only at work or never at night.

Siri Recap does a summary, not a transcription, and it’s not automatic the way Live Rewind is, although it does sound as if you can set it up to always record when you’re at a certain place, so that’s kind of automatic. Apple touted Siri Recap’s privacy with three bullet points:

I think Apple is slicing the baloney pretty thin when it says audio isn’t recorded. Surely there’s some recording because summaries require context; they can’t be made on the fly. Maybe a transcription is done in near-real time and the summary is drawn from that. If so, the transcription is a type of recording, albeit one that isn’t stored after the summary is made. As for not identifying the speakers, I don’t see how that matters. Old-fashioned audio recordings don’t identify speakers, either, but they’re still intrusions on the speakers’ privacy if they didn’t give consent.

Apple has always focused on the privacy of its customers: your information is encrypted, your data stays on your device. It’s following that same pattern here, but the privacy concerns of Live Rewind and Siri Recap aren’t limited to the owners of Apple Watches. Apple now needs think about the privacy of non-customers and be able to explain how that’s being protected, too.

And while an argument can be made that textual transcriptions and recaps aren’t as invasive as saved audio recordings, that doesn’t mean they aren’t invasive at all. That little lock animation Apple’s been using to describe its commitment to privacy has been very effective, but its binary nature doesn’t fit when the products start putting privacy on a sliding scale.

For example, will the Python Software Foundation ever make a Mac app that includes all the documentation I regularly use? And even if they do, is it likely they’ll put in the effort to make better than just visiting the Python Docs web page? Would that be in keeping with their mission? So instead of waiting around for something that will never happen, I used Unite Pro to make a Python Docs site-specific browser.

Launching it takes me straight to the standard library home page, from which I can quickly jump to the docs of whichever module I’m invoking in my current script. I have similar SSBs for the Matplotlib and Pandas documentation.

You might argue that these SSBs aren’t really web apps, that they’re basically a set of static web pages connected by links. That’s nearly true, but while they don’t have the kind of interaction that you see in, say, Google Sheets, they do have search features that make them more interactive than just a list of links. Regardless of how interactive they are, they serve my needs.

You might also suggest I use Dash, an actual app, instead of an SSB for browsing documentation. It incorporates many many sets of documentation and uses local copies so you don’t have to be online to use it. These are all good points and are why I tried Dash several years ago. It just didn’t fit me, probably because searches in Dash returned too many results across too many libraries. There are probably ways to get it to serve up more focused results, but I didn’t want to become a Dash expert (I’m not Brett Terpstra). I just wanted to see documentation relevant to what I was working on at the time. Initially that meant going to the appropriate website; now it means launching the appropriate SSB.

But I’m not a web app absolutist. I recently ended a web app experiment that’s brought me back to a native app. This was with Mastodon and Mona. When Mona 7 came out at the end of last year, I decided to hold off on buying its Ultra in-app purchase. After all, I thought, Mastodon exists on the web. Does it really need an app?

So I made an SSB with Unite Pro for the Mac and used the free versions of Mona on iOS and iPadOS. Eventually, I felt guilty about using an app without paying the developer, so I did the Add to Home Screen thing on my iPhone and iPad a couple of weeks ago to even things out and use the web on all three platforms. It was terrible.

The biggest problem was the lack of timeline syncing and updating. In theory, this problem should have started when I was using Mona on two devices and an SSB on the third. In practice, it wasn’t so bad because I do almost all of my Mastodon reading and posting on my phone. It was when I started using “web Mastodon” on my phone that I noticed how poorly Mastodon updates the timeline.

On the web, Mastodon puts a link at the top of the page saying there are new posts to load into your timeline. When you tap the link, the new posts load, but your position in the timeline can jump around wildly, and then you have to scroll to get back to where you were. A small annoyance, perhaps, but one that happens again and again every day.

And there’s no syncing between platforms with web Mastodon. This is, as I said, less of a problem for me because I’m mainly reading and posting on my phone, but the scrolling necessary on one device to get to where I had been on another just reminded me of all the scrolling described in the previous paragraph, and it seemed worse.

So I subscribed to Mona Ultra and switched to it on all three platforms. The Mastodon web Home Screen icons are gone from my iPhone and iPad, and the SSB is gone from my Mac. Ultra’s extended settings are nice, and I’m happy to pay for them, but the main advantage is the smoother experience I get with a real app written to use the features of the platform(s) it runs on. In this case, one of those features is iCloud syncing.

(By the way, if you feel tempted to tell me about another Mastodon app, like Ivory, don’t. I know about them—I’m happy with Mona.)

In summary, I don’t have any magic tricks for choosing between web apps and native apps. I just know that it’s worth a little time to try out both and see what fits. Every app and every person is different, and you have to decide from direct experience.

I’m pretty sure George Benson never covered “Don’t Leave Me This Way,” but even if he did, that’s not the version I was listening to. It was the version everybody knows by Thelma Houston, with her incredible voice and that fun bass part during the chorus. I’ve been listening to it for 50 years, and it’s unmistakable.

So how did Apple Music get the artist wrong? Is the info provided with the album wrong and Apple is just repeating someone else’s mistake? When I got home, I checked this Heartbreak Hits compilation album on other services. Amazon Music, Spotify, and Tidal all had the album, and they all had the artist listed correctly as Thelma Houston. Only Apple got it wrong.

I don’t think I’ve ever seen mistaken artist attribution like this before, but Apple’s weird choice of album to pluck the song from is very familiar. I listen to a lot of Apple’s Radio Stations and its Essentials and Deep Cuts playlists, and it’s common for a song to be assigned to a compilation album instead of the original source. Even when Apple has the original album in its library. As you might have guessed, I find this annoying.

It’s not exactly wrong to show a song as being on a compilation album; most hit songs have been put on “best of” and other sorts of compilations. But it’s bad scholarship. Yes, if the song was released as a standalone single—as many Beatle songs were—the only album you can assign it to is a compilation, but that’s fairly rare.

If, for example, you look at the Prince Essentials playlist—which you should; it’s fantastic—you’ll see that both “Gett Off” and “1999” are shown as being from his The Hits/The B-Sides album. That’s certainly a fun album to listen to, but neither of those songs “belong” to that album. “Gett Off” is from Diamonds and Pearls, and if I have to tell you where “1999” is from, I don’t know why you’ve read this far.

Apple likes to say that music is part of its DNA. I suggest they schedule some genetic counseling.

I’m using the ancient definition of planet, which includes the Sun and Moon but not anything past Saturn. The numbers are the azimuth and altitude, in that order, and are given to the nearest degree. The idea is to tell me what may be visible and where it is. This particular screenshot was taken just after 10:00 last night; there was no reason to go outside because everything was below the horizon.

I was torn on whether to include the Sun. Few of us need help finding the Sun in the sky, and you can’t see anything other than the Moon when the Sun is up. But I decided to include it anyway, partly for completeness, and partly because the visibility of some bodies depends on their separation from the Sun.

Let’s start with the code that generates the widget’s text. It’s a Python script called planets:

python:
 1:  import astropy.units as u
 2:  from astropy.time import Time
 3:  from astropy.coordinates import get_body, AltAz, EarthLocation
 4:  from subprocess import run
 5:  
 6:  def direction(az):
 7:    'Return a string indication of the azimuth (given in degrees).'
 8:  
 9:    dirs = 'N NNE NE ENE E ESE SE SSE S SSW SW WSW W WNW NW NNW'.split()
10:    i = int(((az + 11.25) % 360) / 22.5)
11:    return dirs[i]
12:  
13:  # Current time in UTC.
14:  ut = Time.now()
15:  
16:  # Observation location.
17:  home = EarthLocation(lat=41.81433*u.deg, lon=-88.07093*u.deg, height=208*u.m)
18:  
19:  # Bodies of interest.
20:  planets = 'Moon Sun Mercury Venus Mars Jupiter Saturn'.split()
21:  
22:  # Current positions of all the bodies.
23:  pos = {}
24:  const = {}
25:  for p in planets:
26:      pos[p] = get_body(p, ut).transform_to(AltAz(obstime=ut, location=home))
27:      const[p] = pos[p].get_constellation()
28:  
29:  # Assemble the results.
30:  output = []
31:  for p in planets:
32:      output.append(f'{p:>8s}: {pos[p].az.value:3.0f} \
33:  {direction(pos[p].az.value):3s} {pos[p].alt.value:3.0f} {const[p]}')
34:  
35:  # Pipe the results through TerminalWidget.
36:  tw = '/Applications/TerminalWidget.app/Contents/MacOS/TerminalWidget\
37:   --target planets --font Menlo --bg eeeeee --fg 000000 --text -'.split()
38:  run(tw, input='\n'.join(output).encode())
39:  
40:  # print('\n'.join(output))

There’s no shebang line because of how it gets called by launchd, which we’ll get to later.

After planets imports the necessary modules, Lines 6–11 define the direction function, which takes the azimuth and returns a string with the corresponding point of the compass. I have this because 223°, which is how Astropy reports the azimuth, doesn’t immediately say “southwest” to me. The function assumes a 16-point compass, like this one:

Image from Wikipedia.

The points are separated by 22.5°, which is why there’s a division by 22.5 in Line 10. The other parts of Line 10 adjust for the fact that North starts at 348.75° (-11.25°), the azimuth resets at 360°, and the index of a list must be an integer. Astropy may already have a function that does what direction does, but I thought it would be easier (and more fun) to write the function myself than to search through the documentation.

Lines 14 and 17 define the time and place of observation. planets will be run every half hour to update the widget, so what’s being displayed is never more than 30 minutes out of date. The home location you see above is actually the Morton Arboretum; my version of the script uses the latitude and longitude of my house.

Line 20 defines the planets list, and Lines 23–27 create a pair of dictionaries, pos and const, which contain the AltAz position and constellation of each planet. The get_body function (Line 26) gets the position, and the get_constellation function (Line 27) uses that position to figure out the constellation the body is in.

Lines 30–33 create the list of output lines, and Lines 36–38 use the run function of the subprocess module to send the output lines to TerminalWidget. The tw list contains both the full path to the TerminalWidget executable and all the options passed to it. The input parameter to run is the previously defined output, converted to a single string separated by linefeeds and encoded as bytes.

Line 40 is basically a debugging line that I’ve left in for future development. While writing planets, I had Lines 36–38 commented out and Line 40 uncommented so I could see the results immediately in the Terminal.

planets is run by launchd every 30 minutes, on the hour and half-hour, via this launch agent, com.leancrew.planets.plist:

xml:
 1:  <?xml version="1.0" encoding="UTF-8"?>
 2:  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 3:  <plist version="1.0">
 4:  <dict>
 5:    <key>Label</key>
 6:    <string>com.leancrew.planets</string>
 7:    <key>ProgramArguments</key>
 8:    <array>
 9:      <string>/path/to/python</string>
10:      <string>/path/to/planets</string>
11:    </array>
12:    <key>StartCalendarInterval</key>
13:    <array>
14:      <dict>
15:        <key>Minute</key>
16:        <integer>0</integer>
17:      </dict>
18:      <dict>
19:        <key>Minute</key>
20:        <integer>30</integer>
21:      </dict>
22:    </array>
23:  </dict>
24:  </plist>

The first item in the ProgramArguments array is the full path to the Python executable (this is why planets doesn’t need a shebang line), and the second item is the full path to the planets script itself. The schedule for running planets is in the StartCalendarInterval array—whenever the minute is 0 or 30, the script is run.

As I write this, a solar eclipse is nearly underway. Here in the Chicago area, it’s going to be a very partial eclipse—only 1% of the Sun will be blocked. Since 100% of the Sun is being blocked by clouds, I won’t be able to see any of the eclipse. But my planets widget is showing me, more or less, that it’s happening above the clouds.

Rounding the Sun and Moon’s positions to the nearest degree isn’t precise enough to determine an eclipse, but it’s a decent hint.

I’m often out walking at night, and a few months ago—when Mercury, Venus, and Jupiter were near each other and close to Castor and Pollux, the Gemini twins—I started thinking it would be nice to be able to write little scripts that would tell me where the planets were and when they’d be easily visible. One of the fun features would be including information on which constellation the planets were in.

This led me on a fun journey of discovery, the sort of thing AI companies want us to forget how to do. I learned that official boundaries for the Western constellations were defined only about a century ago and that although they were defined in a very simple way, corresponding to lines of right ascension and declination, precession of the equinoxes has since made those boundaries more complicated. They still look pretty well aligned, but they aren’t. Here’s the IAU image of Aries:

If you look at the right ascension and declination coordinates of the points on its boundary, you’ll see that successive points don’t have the same RA or Dec values. Close, but not the same.

02 06 39.6594| 10.5143948|ARI 
01 46 37.3761| 10.5432396|ARI 
01 46 58.7219| 25.6263351|ARI 
02 02 03.2907| 25.6050701|ARI 
02 02 07.3479| 27.8550186|ARI 
02 32 16.8357| 27.8047638|ARI 
02 32 24.7665| 31.2213154|ARI 
02 50 30.8112| 31.1865025|ARI 
03 29 42.4003| 31.1003609|ARI 
03 29 09.7494| 19.4343338|ARI 
03 24 08.9363| 19.4461136|ARI 
03 23 47.1387| 10.3632069|ARI 

I also learned that there are a crapload of reference frames, and you had better know which one is being used for the data you’re accessing.

This is one of the things that led me to abandon Mathematica and the Wolfram Language for these calculations. Despite Wolfram’s promises of great solutions for astronomy, my test notebook showed that the RA and Dec for the Sun, for example, aren’t reported in the same frame as the RA and Dec of stars. This isn’t necessarily bad—it could be more natural to use one frame for one sort of object and another frame for another sort—but the documentation needs to tell you what frames are being used and how to convert between them. I never found that explanation, so I started exploring Python solutions.

There are two main Python modules for doing the kind of calculation I’m interested in: Astropy and Skyfield. Astropy is the standard Python module (or set of modules) for doing all sorts of astronomical calculations; Skyfield seems to be more focused on observational astronomy. That would suggest I should use Skyfield, but after looking through the documentation, I decided to get my feet wet with Astropy because it looked simpler. I can always switch to Skyfield if I find myself bumping up against some limitations in Astropy.

(I should also mention SPICE, which is NASA’s software toolkit for working with the positions of planets and other objects in space. It has a Python wrapper for its C version, and having the imprimatur of NASA certainly made it attractive. But it doesn’t have actual Python documentation; it wants users to refer to the C documentation to figure out how the Python functions work, and I’m not interested in that.)

Having settled on Astropy, I wrote up a little script this afternoon to see if my brief review of the documentation was enough to do some of the calculations I was interested in. The script calculates the position of the Sun today at 2:00 PM CDT, and converts the result into a form that I can compare with the NOAA Solar Calculator page.

I’ve set the observation point to the visitor center at the Morton Arboretum. The results of interest are the azimuth and altitude (or elevation) of the Sun at the appointed date and time. Here’s a zoomed-in view of the lower right corner:

So a person at the Arboretum at 2:00 would see the Sun in the southwest, 211.59° from north, at 60.35° up from the horizon. NOAA’s altitude calculation includes an atmospheric correction, the formula for which is given on a linked page.

Here’s my little script:

python:
 1:  #!/usr/bin/env python3
 2:  
 3:  from astropy.coordinates import ICRS, AltAz, EarthLocation, get_sun
 4:  from astropy.time import Time
 5:  import astropy.units as u
 6:  from trigd import *
 7:  
 8:  # 2:00 PM Central Daylight Time on August 10, 2026.
 9:  utcoffset = -5*u.hour
10:  time = Time('2026-8-10 14:00:00') - utcoffset
11:  
12:  # Location of Morton Arboretum visitor center.
13:  morton = EarthLocation(lat=41.81433*u.deg, lon=-88.07093*u.deg, height=208*u.m)
14:  
15:  # Sun position in GCRS (default).
16:  sun = get_sun(time)
17:  
18:  # The constellation it's in.
19:  constellation = sun.get_constellation()
20:  
21:  # Sun position as azimuth and altitude
22:  sun_altaz = sun.transform_to(AltAz(obstime=time, location=morton))
23:  
24:  # The default transformation to AltAz makes no adjustment for refraction.
25:  # Use the NOAA refraction formula to adjust altitude for comparison
26:  # with the NOAA value.
27:  def noaa_refraction(alt):
28:    t = tand(alt)
29:    return (58.1/t - .007/t**3 + .000086/t**5)/3600
30:  
31:  # Print the results.
32:  az = sun_altaz.az.value
33:  alt = sun_altaz.alt.value
34:  alt_adj = alt + noaa_refraction(alt)
35:  print(f'      Azimuth: {az:-6.2f}°')
36:  print(f'     Altitude: {alt:-6.2f}° (without refraction)')
37:  print(f'     Altitude: {alt_adj:-6.2f}° (with NOAA refraction)')
38:  print(f'Constellation: {constellation}')

The script starts by importing various Astropy submodules and my trigd module, which calculates trigonometric functions for degrees instead of radians. We’ll use that to match NOAA’s atmospheric correction formula.

Lines 9 and 10 set the date and time as an Astropy Time object. Line 13 sets the location to the visitor center. Line 16 gets the position of the Sun at that time in the Geocentric Celestial Reference System (GCRS) frame. Line 22 then transforms the position to azimuth and altitude as viewed from the visitor center.

Because I didn’t include any atmospheric information in the AltAz specification, it assumes a vacuum and does no refraction adjustment. I did it that way so I could use NOAA’s refraction formula instead of whatever Astropy does. That formula is defined in Lines 27–29 (which uses the tand function to calculate the tangent of an angle given in degrees), and the adjusted altitude is calculated in Line 34.

Lines 35–38 print out the results, which look like this:

      Azimuth: 211.59°
     Altitude:  60.34° (without refraction)
     Altitude:  60.35° (with NOAA refraction)
Constellation: Cancer

We’ll return to the constellation part later. As you can see, the azimuth and adjusted altitude match the NOAA values to two decimal places, which made me feel pretty good.

As for the constellation the Sun was in at the specified time, that’s calculated by the aptly named get_constellation function on Line 19. The great thing about get_constellation is that it understands the reference frame of the object it’s called from and does whatever transformations are needed (in this case to ICRS) to figure out which constellation that object is in. The answer was printed out by Line 38.

To check on the constellation answer, I went to Heavens Above, a site I’ve been using since the late 90s. I entered the Arboretum location and 2:00 PM today as the time, and HA told me the Sun was in Cancer, just like Astropy. It also showed me this sky chart:

The Sun was clearly near the end of its time in Cancer and would soon be in Leo. So I began a trial-and-error search at Heavens Above and with Astropy in an interactive Python session to find out when the Sun would move from Cancer to Leo.

Heavens Above told me that the Sun would enter Leo at 8:00:15 PM today. Astropy said it would happen at 8:07:23 PM. I suspect Heavens Above is giving the better answer, as I’ve been using Astropy in its most basic configuration. There are ways to set up Astropy to use ephemerides data, which should give more accurate positions. That’ll be my next step.

By the way, a 7-minute difference isn’t much. The Sun moves along the ecliptic at a rate of about 1° per day (roughly 360° in 365 days), and 7 minutes is about 0.005 of a day (7/1440). That means the difference between the Heavens Above Sun position and the Astropy Sun position is about 0.005°. Do I need the position of the Sun (or any of the planets) to a greater precision than that? No, but that won’t stop me from exploring ways to do so.

The code I ran to get this two-month calendar on my Desktop was

bash:
if [ $(date +"%-d") -gt 15 ]; then
  cal -A 1
else
  cal -B 1
fi |\
terminal-widget --target cal --font Menlo --bg "#eeeeee" --text -

I have since updated a couple of things and need more room to talk about it all.

First, the app that put that widget on my Desktop is Brett Terpstra’s TerminalWidget, which he just released. As a one-time user of GeekTool, I’ve been waiting for TerminalWidget since Brett first began talking about it. While GeekTool and the similar NerdTool might still work, I wanted an app that worked with macOS’s modern widget system. TerminalWidget does.

I put a medium-sized widget in the upper-left corner of my Desktop by dragging one out from the widget editor window. If you’ve never done this before (I hadn’t), read Apple’s instructions.

I then right-clicked on the widget and renamed it cal. Now it’s ready for me to run the command that puts the calendar into the widget.

The command is a pipeline, and the executable after the pipe is terminal-widget. This is a symbolic link to the command that’s buried in the TerminalWidget app package. I created the link with

ln -s /Applications/TerminalWidget.app/Contents/MacOS/TerminalWidget ~/bin/terminal-widget

where ~/bin is a directory in my $PATH.

I won’t go through the options given to terminal-widget; they’re explained in TerminalWidget’s CLI page. Suffice it to say that the options put whatever is sent to terminal-widget into the cal widget and format it the way I want.

Instead, let’s talk about the command that comes before the pipe:

bash:
if [ $(date +"%-d") -gt 15 ]; then
  cal -A 1
else
  cal -B 1
fi

I think this will run in any Bourne-like shell. I know it runs in zsh and bash.

The idea is to run the cal command, displaying the current month and either the month before or the month after. Which other month to show is determined by the if statement at the top. It runs the date command and formats the output as just the day of the month with no leading zero. If this is greater than 15, cal is passed the option to show one month after the current month. Otherwise, cal is passed the option to show one month before the current month.

(Brett uses cal as one of his example widgets, but his command doesn’t include an if. It always displays the current month and the month after.)

By the way, if you run the above command in the Terminal, you’ll notice its output is slightly different from what’s shown in the widget:

The current date is highlighted. I think this is because cal is written to format its output as plain text when it’s being saved to a file or piped to another command but jumps back to invert today’s date when it’s being run in a terminal. It’s similar to the way ls lists files one per line when being piped but formats them in columns when its output goes to a terminal.

OK, this is nice for testing out TerminalWidget, but running this command once won’t get it to change when we get past the 15th of the month. It needs to be run every day, preferably in the morning.

The classic Unix way to schedule tasks is cron, but according to Apple your Mac must be awake when a cron job is scheduled. If it isn’t, the job runs the next time the job is scheduled and the Mac is awake. Because I don’t know when my MacBook Pro will be awake, cron is not a good option for scheduling this task. I need to use launchd, which will run the specified command at the scheduled time or the next time the Mac wakes up.

The easiest way to set up launchd agents is to use LaunchControl and let its GUI handle the tricky bits, but you can do it by hand if you must. First, make a plist file that describes what command is to be run and when and save it in your ~/Library/LaunchAgents folder. Here’s the file, named com.leancrew.calwidget.plist, that LaunchControl built for me:

xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.leancrew.calwidget</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/zsh</string>
    <string>/Users/drang/bin/calwidget.sh</string>
  </array>
  <key>StartCalendarInterval</key>
  <array>
   <dict>
    <key>Hour</key>
    <integer>6</integer>
    <key>Minute</key>
    <integer>30</integer>
   </dict>
  </array>
</dict>
</plist>

The ProgramArguments section tells launchd to run my calwidget.sh script via zsh. Because launchd commands aren’t run under my usual environment, I give full file paths to both zsh and my script. The StartCalendarInterval section tells launchd to run the job every day at 6:30 AM.

The calwidget.sh script is basically what we’ve seen before, but with a couple of small changes:

bash:
if [ $(date +"%-d") -gt 7 ]; then
  cal -A 1
else
  cal -B 1
fi |\
/Applications/TerminalWidget.app/Contents/MacOS/TerminalWidget \
  --target cal --font Menlo --fg "000000" --bg "eeeeee" --text -

I decided I’d prefer to see the month before the current month only if we’re a week or less into the current month. Hence the change from 15 to 7 in the if statement. Also, I changed the terminal-widget command to the full path of the executable it’s linked to because launchd doesn’t know my usual $PATH. And finally, I added a --fg option to ensure that both the foreground and background colors are what I want—I decided not to rely on defaults.

I loaded this job into launchd via LaunchControl, but I also tested doing it with launchctl:

launchctl load -w ~/Library/LaunchAgents/com.leancrew.calwidget.plist

The launchctl man page calls load a “legacy subcommand,” suggesting that I should learn the newer way of doing things, but I find the descriptions of the recommended subcommands incomprehensible. And I haven’t found a good tutorial for them. Again, LaunchControl just does what I want it to do.

While this exercise was mostly a proof of concept, I do like having quick access to a two-month calendar and will probably keep this widget. Now I need to think about what other information I want immediate access to.

My fundamental rule is Don’t, but a single word wouldn’t make for much of a blog post.

In what follows, I hope to explain how I’ve come to that rule and the exceptions I make to it. I’ve been thinking about how I use and don’t use spreadsheets quite a bit lately. This introspection was inspired in part by Allison Sheridan’s presentation at Macstock (which you can see on her site along with a couple of other recent spreadsheet posts) and in part by my recent use of Numbers to make difference tables and clean up a table of data.

Let’s start by considering what makes spreadsheets so attractive. Right off the bat, you’re presented with a grid of cells that act as data containers. You don’t have to define these containers, you don’t have to name them, you don’t have to initialize them—they’re just there, waiting for you to fill them as you see fit.

When it comes time to start operating on this data, you still don’t have to name the cells. You just click (or click and drag) to fill in the function arguments. The spreadsheet app fills in the appropriate row/column reference. If you want a reminder of what a cell is for, you can type a name or description in an adjacent cell. Similarly, you don’t have to figure out the appropriate order of the operations. The app works out the cell dependency chain and recalculates everything, everywhere, all at once.

And because you can set the size, color, border, and font styling of every cell, your spreadsheet can generate nice-looking tables for inserting into your reports, memos, and slideshows.

So a spreadsheet is a data store, a logic machine, and a presentation tool. Are you getting it?

But if spreadsheets are all that, where does my Don’t rule come from? There are many sources, but I’d have to say I’ve been strongly influenced by the last 10–15 years of my working life, during which time I had to analyze dozens and dozens of data sets, all of which were sent to me as Excel spreadsheets. The engineering firms that sent me the spreadsheets had created them not simply as data stores. They included some of their own analysis (which typically overlapped slightly with mine), and they formatted the spreadsheets as tables to put into their own reports. This made my work harder for a few reasons:

1. Because I had to make sure I understood and agreed with their analysis, I had to review all their formulas. Some of these formulas were complex—nested IF statements are easy to follow in a traditional programming language, but they’re a mess in a spreadsheet. Some were inconsistent—different rows in the same table would have different formulas, as if they were written by different people at different times or adapted from a spreadsheet on a previous project. Some of them referred to cells that were far away and required a lot of scrolling to track down. None of them—not a single one in over a decade—used cell names to help make the formulas easier to understand.

   The complicated formulas mentioned above sometimes—not often, but sometimes—contained mistakes. And sometimes the formulas were correct, but the descriptions in the header cells were wrong. This meant phone calls were needed to resolve the discrepancies, further slowing the analysis.

2. It was common for the data to be split over two or more sheets. I think this was done mainly to make the tables fit better into the other engineers’ reports, which was fine for their purposes but not for mine. I had to recombine the data for my analyses. Also, the sheets often had complicated, multiline headers, which meant I couldn’t just export them as CSV files.
3. Every engineer I worked with built their spreadsheets in a different way. Those who worked for the same firm didn’t adhere to an “ABC Engineering” house style. Even individual engineers would change their spreadsheet styling from one project to the next. Basically, every spreadsheet that came in the door was sui generis, and I had to do all the data cleaning by hand. This slowed me down, not only because I couldn’t rely on automation for this step, but also because I had to double- and triple-check my work to avoid copy/paste mistakes.

Fundamentally, this experience—especially Item 1—soured me on the use of spreadsheets for anything large or complex. The engineers I was working with were smart, but their spreadsheets weren’t. My conclusion was that the simplicity of the typical click-and-drag method of assembling a spreadsheet encouraged poor organization and errors as the spreadsheets grew or were adapted to new data. It’s easy to say “Oh, I would never do that,” but I’m old enough to know that I would do that. I see the ease with which I can build spreadsheets with today’s apps as a Siren song that will lead me onto the rocks.

(If you’re getting ready to write to me about the Reinhart/Rogoff paper, you can relax. It is the prime example of elementary spreadsheet errors—errors that two Harvard professors would surely never make—and it led to a lot of suffering through unnecessary government austerity policies. And if you’re now getting ready to write to me about how Reinhart and Rogoff’s errors don’t negate the essential truth of their conclusions, you can just fuck off.)

The convenience of having the data and the analysis logic in the same document becomes a problem when you have to apply that logic to several datasets, especially when they differ in size. Spreadsheet templates are great when the data allow you make several spreadsheets with the exact same layout, but the data I tend to deal with don’t fit that rigid pattern. If I’m doing, for example, analyses and plots of several time series, those series seldom extend over the same length of time and the same number of data points. It’s far easier to deal with these size differences when the logic is in a program, separated from the data.

Another problem with spreadsheets is that the amount of data they can contain is more limited than when you use other data analysis workflows. The size limits on spreadsheets are, admittedly, quite large, but in an era of Big Data “quite large” may not be big enough. In her Macstock talk, Allison shows how she ran into that problem with the data set of US baby names. Let’s take a detour to talk about handling that data.

One of the ways you can download the baby name dataset is as a zipped collection of CSV files. Each file in the collection is associated with one year and has a name like yob1960.txt. The contents look like this:

Mary,F,51472
Susan,F,39208
Linda,F,37316
Karen,F,36378
Donna,F,34138
[etc]

where the first item is the name, the second is the sex at birth, and the third is the number of babies given that name in that year. The lines are ordered first by sex and then by number. If you concatenate all the files, you’ll find there are 2,181,032 entries. As Allison found out, this won’t fit into an Excel spreadsheet, as Excel is limited to 1,048,576 rows. That’s the very computery number $2^{20}$ or ${1024}^2$. The limit in Numbers is the less computery but more human 1,000,000 rows.

Allison got around the size problem by… er… cheating. She eliminated the less popular names to get the list to fit into Excel, and then demonstrated some pivot table stuff. You can see it starting at 1:13:50 in the video.

I decided to do something similar to her work but without the cheating. First, I concatenated all the individual files into one big CSV file that also included a field for the year. That was done through these shell commands:

echo 'Year,Name,Sex,Count' > all-years.csv
for f in yob*.txt; do
  y=${f:3:4}
  sed -e "s/\r$//;s/^/$y,/" $f >> all-years.csv
done

The year is extracted from the file name through substring expansion and then added to the beginning of each line via sed. The original files are in Windows format with CRLF line endings, so the sed command also deletes the CR characters. The upshot of all this is a file (with Unix line endings) named all-years.csv that looks like this:

Year,Name,Sex,Count
1880,Mary,F,7065
1880,Anna,F,2604
1880,Emma,F,2003
1880,Elizabeth,F,1939
1880,Minnie,F,1746
[etc]

(Yes, even though the data set is said to have come from Social Security registrations, it starts in 1880, decades before the Social Security Act. I can’t explain that. Nor can I explain how Minnie was once the fifth most popular girls’ name.)

I’m going to use Python and Pandas to extract the five most popular girls’ names from 2001 through 2025 (the last year in the dataset). Here’s the start of a simple interactive Python session that does it:

>>> import pandas as pd
>>> df = pd.read_csv('all-years.csv')
>>> cols = ['Name', 'Count']

This reads the CSV file into a dataframe and defines the columns of the dataframe that we want to include in our output. The >>> at the beginning of each line is the interactive Python prompt. Here’s how we get the list of names we’re interested in:

>>> df[(df.Sex=='F') & (df.Year>2000)][cols].groupby('Name')\
... .sum().sort_values('Count', ascending=False)[:5]
           Count
Name            
Emma      449576
Olivia    423613
Isabella  381577
Sophia    368619
Emily     353077

The ... indicates a continuation input line. Everything after that is output.

Reading through the command, we see that we’re

1. getting the subset of data consisting of girls born after 2000;
2. limiting the output to the Name and Count fields;
3. grouping the output by Name;
4. summing the Counts for each Name;
5. sorting the results by Count in descending order; and
6. limiting the output to the top five names.

That’s obviously a long command, but you can see how it’s constructed in a logical fashion.

If we want to compare these to the popular girls’ names from a century earlier, the command is very similar:

>>> df[(df.Sex=='F') & (df.Year>1900) & (df.Year<=1925)][cols].groupby('Name')\
... .sum().sort_values('Count', ascending=False)[:5]
            Count
Name             
Mary      1056333
Helen      505522
Dorothy    475151
Margaret   402317
Ruth       364923

My wife and I had great aunts with some of these names.

If you’re a database maven, you recognize the Pandas groupby function as a copy of the SQL GROUP BY construct. Let’s redo this in an interactive session with SQLite. We start by importing the data from the CSV file:

sqlite> .mode csv
sqlite> .import all-years.csv names
sqlite> .mode columns

The mode is set to csv in order to import the data, then set back to columns to make the output look the way we want.

Now we get the top five girls’ names from the 21st century and show them in descending order:

sqlite> select Name, sum(Count) from names
     ...> where Sex is "F" and Year > 2000
     ...> group by Name order by sum(Count) desc limit 5;
Name      sum(Count)
--------  ----------
Emma      449576    
Olivia    423613    
Isabella  381577    
Sophia    368619    
Emily     353077    

SQL is certainly more English-like, but you can see the parallels between it and Pandas. Now for the early 20th century:

sqlite> select Name, sum(Count) from names
     ...> where Sex is "F" and Year > 1900 and Year <= 1925
     ...> group by Name order by sum(Count) desc limit 5;
Name      sum(Count)
--------  ----------
Mary      1056333   
Helen     505522    
Dorothy   475151    
Margaret  402317    
Ruth      364923    

Allison does similar things with her truncated Excel file using pivot tables. I hate the name “pivot table,” because I think it’s an obscure term for the simple operations of grouping and summarizing. For some reason, my feelings on this don’t matter, and pivot tables are here to stay. Pandas has even added a pivot_table function to placate people who’ve come over from Excel. Under the hood, pivot_table calls groupby.

Well, that was kind of a long detour, and I forgive you if you’ve forgotten where we were. I had just gone through a list of things that made me leery of using spreadsheets—why my first rule of using spreadsheets is Don’t.

But I allow for exceptions. My two main exceptions are:

1. When the problem is both small enough to see on the screen with almost no scrolling and the operations are simple enough to be easily understood without counting commas and parentheses. That was what I did for my sum of cubes difference tables. The formulas consisted mainly of subtractions, with some power and division operations here and there. Only the simultaneous equations solution in the lower right involved actual function calls, and there were no nested calls.

   

2. When I’m using the spreadsheet as a way station for editing data before passing it along. I did that in the baseball team progress post to edit down the large and unwieldy season results tables from Baseball Reference. It was fast and easy to select the table in Safari, paste it into Numbers, and then delete the columns and rows I didn’t need. But I did it this way only because this was a one-off project. If I were given the job of making progress charts for all 30 teams every day of the season, I’d never do it by hand like that. I’d use the Pandas read_html function to pull the HTML table into a dataframe and a variety of drop commands to pare it down.

I used to use spreadsheets for data entry, too, but not anymore. It was once the only reliable way to put a table of numbers found in a book into electronic form. But OCR has gotten so much better, I can’t remember the last time I did this.

I know there are lots of people who love using spreadsheets. They’ve spent a lot of time learning the ins and outs and don’t want to switch to another tool. That’s fine. This post was about my rules, not anyone else’s. I’m not saying good, accurate, complex work can’t be done in spreadsheets. It just won’t be done by me.