As I typed out the reply, though, the reasons seemed weaker. Yes, it’s true that the full moon that determines this year’s date of Easter (and therefore Ash Wednesday) isn’t part of the same lunation that determines the start of Ramadan and Chinese New Year, so there was an astronomical reason to keep Ash Wednesday out of the post. But it’s also true that both Ramadan and Lent represent periods of self-denial, so there’s a cultural connection.

Adding a new bit of Emacs Lisp code to what I’d already written to include a check for Ash Wednesday wouldn’t be hard, but another thought was buzzing in my head: switching from Emacs Lisp to Common Lisp. The ELisp calendar functions were written by Edward Reingold and Nachum Dershowitz, authors of the well-known Calendrical Calculations. That book includes a lot of code that isn’t in the Emacs implementation, code that does astronomical calculations I’d like to explore. So it seemed like a good idea to write a Ramadan/Lent/Chinese New Year script in Common Lisp and use the functions from the book.

The problem with that idea was that the Common Lisp code I downloaded from the Cambridge University Press site, calendar.l, didn’t work. I tried it in both SBCL and CLISP, and calling

(load "calendrical.l")

threw a huge number of errors. I was, it turned out, not the first to have run into this problem. The workarounds suggested there on Stack Overflow didn’t help. There’s a port to Clojure that apparently works, but I was reluctant to use Clojure and have to maintain both it and a Java Virtual Machine.

What I found, though, was that Reingold & Dershowitz’s code would load in CLISP with one simple change. After many lines of comments, the working part of calendar.l starts with these lines:

(in-package "CC4")

(export '(
          acre
          advent
          akan-day-name
          akan-day-name-on-or-before

          [and so on for a few hundred lines]

          yom-ha-zikkaron
          yom-kippur
          zone
          ))

Deleting these lines got me a file that would load without errors in CLISP,¹ so I named the edited version calendar.lisp and saved it in my ~/lisp/ directory. I believe the problem with the unedited code has something to do with packages and namespaces, and if I keep using Common Lisp long enough, I may learn how to make a better fix. Until then, this will do.

With a working library of calendar code, I wrote the following script, ramadan-lent, to get the dates for which Ramadan 1 and Ash Wednesday correspond over a 500-year period:

 1:  #! /usr/bin/env clisp -q
 2:  
 3:  ;; The edited Calendrical Calculations code by Reingold and Dershowitz
 4:  (load "calendar.lisp")
 5:  
 6:  ;; Names
 7:  (setq
 8:    weekday-names
 9:    '("Sunday" "Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday")
10:  
11:    gregorian-month-names
12:    '("January" "February" "March" "April" "May" "June"
13:      "July" "August" "September" "October" "November" "December"))
14:  
15:  ;; Date string function
16:  (defun gregorian-date-string (date)
17:    (let ((g-date (gregorian-from-fixed date))
18:          (weekday (day-of-week-from-fixed date)))
19:      (format nil "~a, ~a ~d, ~d"
20:        (nth weekday weekday-names)
21:        (nth (1- (second g-date)) gregorian-month-names)
22:        (third g-date)
23:        (first g-date))))
24:  
25:  ;; Get today's (Gregorian) date.
26:  (multiple-value-setq
27:    (t-second t-minute t-hour t-day t-month t-year t-weekday t-dstp t-tz)
28:    (get-decoded-time))
29:    
30:  ;; Loop through 500 Islamic years, from 250 years ago to 250 years in
31:  ;; the future and find each Ramadan 1 that corresponds to Ash Wednesday.
32:  ;; Print as a Gregorian date.
33:  (setq
34:    f (fixed-from-gregorian (list t-year t-month t-day))
35:    ti-year (first (islamic-from-fixed f)))
36:  (dotimes (i 500)
37:    (setq iy (+ (- ti-year 250) i)
38:          r (fixed-from-islamic (list iy 9 1))
39:          g-year (gregorian-year-from-fixed r)
40:          aw (- (easter g-year) 46))
41:    (if (equal aw r)
42:      (format t "~a~%" (gregorian-date-string r))))

The -q in the shebang line tells CLISP not to put up its typical welcome banner. I had to write my own gregorian-date-string function (Lines 16–23) because calendrical.lisp doesn’t have one, but it was pretty easy.

In fact, it was all pretty easy. I haven’t programmed in Lisp or Scheme in quite a while, but I quickly remembered how fun it is. The only tricky bits were:

• learning how to handle the multiple value output of get-decoded-time (Lines 26–28);
• remembering how to handle more than one variable assignment in setq; and
• recognizing that what the ELisp calendar library calls “absolute” dates, the Common Lisp calendar library calls “fixed” dates.

R&D’s library has an easter function for getting the date of Easter for a given (Gregorian) year; Line 40 gets the date of the associated Ash Wednesday by going back 46 days from Easter.

The output of ramadan-lent was

Wednesday, February 6, 1799
Wednesday, February 24, 1830
Wednesday, February 22, 1928
Wednesday, February 18, 2026
Wednesday, March 7, 2057
Wednesday, February 16, 2124
Wednesday, March 5, 2155
Wednesday, February 13, 2222
Wednesday, March 2, 2253

The most common gap between successive correspondences was 98 years, but there were occasional gaps of 31 and 67 years.

It took only a few extra lines at the end to include a check for Chinese New Year. Here’s ramadan-lent-new-year:

 1:  #! /usr/bin/env clisp -q
 2:  
 3:  ;; The edited Calendrical Calculations code by Reingold and Dershowitz
 4:  (load "calendar.lisp")
 5:  
 6:  ;; Names
 7:  (setq
 8:    weekday-names
 9:    '("Sunday" "Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday")
10:  
11:    gregorian-month-names
12:    '("January" "February" "March" "April" "May" "June"
13:      "July" "August" "September" "October" "November" "December"))
14:  
15:  ;; Date string function
16:  (defun gregorian-date-string (date)
17:    (let ((g-date (gregorian-from-fixed date))
18:          (weekday (day-of-week-from-fixed date)))
19:      (format nil "~a, ~a ~d, ~d"
20:        (nth weekday weekday-names)
21:        (nth (1- (second g-date)) gregorian-month-names)
22:        (third g-date)
23:        (first g-date))))
24:  
25:  ;; Get today's (Gregorian) date.
26:  (multiple-value-setq
27:    (t-second t-minute t-hour t-day t-month t-year t-weekday t-dstp t-tz)
28:    (get-decoded-time))
29:    
30:  ;; Loop through 500 Islamic years, from 250 years ago to 250 years in
31:  ;; the future and find each Ramadan 1 that corresponds to Ash Wednesday
32:  ;; and Chinese New Year.
33:  ;; Print as a Gregorian date.
34:  (setq
35:    f (fixed-from-gregorian (list t-year t-month t-day))
36:    ti-year (first (islamic-from-fixed f)))
37:  (dotimes (i 500)
38:    (setq iy (+ (- ti-year 250) i)
39:          r (fixed-from-islamic (list iy 9 1))
40:          g-year (gregorian-year-from-fixed r)
41:          aw (- (easter g-year) 46))
42:    (if (equal aw r)
43:      (let ((ny (chinese-new-year-on-or-before r)))
44:        (if (equal ny (1- r))
45:          (format t "~a~%" (gregorian-date-string r))))))

The chinese-new-year-on-or-before function (Line 43), which is in the library to aid in the writing of the typically more useful chinese-from-fixed function, turned out to be just what I needed here. It gets me the fixed date of Chinese New Year that’s on or before Ramadan 1. I then check to see if that’s exactly one day before Ramadan 1 in Line 44.

This script’s output was

Wednesday, February 6, 1799
Wednesday, February 18, 2026
Wednesday, February 16, 2124
Wednesday, February 13, 2222

We see that last week’s triple correspondence hadn’t occurred in 227 years, and it’ll be another 98 years before the next one. Thanks to TJ for getting me to look into this rare event.

I’ve had a copy of the second edition of Calendrical Calculations (called the Millenium Edition because it came out in 2001) for over twenty years. As I was fiddling with ramadan-lent and ramadan-lent-new-year, I ordered the fourth (or Ultimate) edition so I’d have the best reference on the functions in calendar.lisp. You can expect more posts on calendars and astronomical events as I dig into it.

I thought some of you might be wondering about the dimensions on this drawing from yesterday’s post:

Don’t be offended—I trust you all to know why the horizontal components of the two diagonals are $r_0/\sqrt{2}$ and $r_1/\sqrt{2}$. What I thought you might be questioning was my use of short diagonal ticks instead of arrowheads on the dimension lines along the bottom of the drawing.

This is a style I picked up as an undergrad. I use it all the time in hand-drawn sketches, and I think I’m going to use it here from now on. The first person I saw using this kind of dimension line was John Haltiwanger, who taught the second structural analysis class I took, and I adopted it in emulation of him. I mentioned Prof. Haltiwanger and his insistence on good sketches in this post last year.

There are two advantages to using ticks instead of arrowheads: speed and clarity. The speed advantage is obvious. Clarity comes in drawings of structural problems, where we use arrowheads to represent forces. Although it’s usually clear from context which lines are for forces and which are for dimensions, sometimes the two cross or are close enough to one another that it helps to use different ends. This is especially true when sketching on paper or a blackboard, where you can’t use line thickness to distinguish between the two.

Let’s say I’m going to analyze a simply supported beam with a uniformly distributed load across its entire length and a concentrated load at its center. I’d sketch it this way in my notebook:

After drawing the beam, supports, and forces, I make the vertical leader lines, one long dimension line the full length of the beam, and then three quick diagonal ticks.

If I’m going to blog about it, I’ll turn it into a nicer drawing in OmniGraffle:

Using blue for the leader and dimension lines—and making them thinner—is a good way to distinguish them from forces, and I’ve been doing that for years.¹ I’ve usually used a different style of arrowhead for the dimensions than for the forces. OmniGraffle has a huge number of arrowhead styles:

I’ve generally used the “Filled Arrow” for forces and the “Sharp Arrow” for dimensions. You might think I’d use the “Dimension Arrow,” but I’ve never liked it. It has a little leader line attached to it, which is, unfortunately, pretty much useless because it’s always the same length. Leader lines are supposed to draw your eye from the object to the dimension line—they have to be different lengths, and they’re usually much longer than the tiny ticks OmniGraffle provides.

I could continue to use the sharp arrows, of course, but I’ve decided my drawings here should look more like the sketches I make in my notebook. And it’s a nice tribute to Prof. Haltiwanger. Although his was my second structural analysis class, it was the one in which I began to truly appreciate the topic.

While I’m at it, I should mention that I made a set of stencils with objects commonly seen in structural analysis drawings.

The top two rows show fixed, simple, and guided ends; the bottom two rows show springs. There are four variations on simple ends; the differences depend on whether there’s a roller and whether I want to show the hinge explicitly. There’s only one linear spring, but I needed four rotational springs to account for different angles of attachment. All of these can be rotated as needed once they’re placed in an OmniGraffle document.

Here’s a geometry puzzle from the March issue of Scientific American. If you see the trick, it’s easy to solve.¹ After doing it the easy way, I decided to solve it again the hard way, as if I hadn’t noticed the trick.

Here’s the puzzle:

A red circle is inscribed inside a blue square. The arrangement leaves gaps in the square’s four corners, two of which are filled with smaller circles that just barely touch the big red circle and the two corner sides of the blue square. This, in turn, leaves two smaller gaps in the corners, which are filled with smaller circles, and so on, with ever smaller circles ad infinitum. The entire diagram is inscribed inside of a 1 × 1 gray square. What is the total circumference of all the circles?

Without the trick, we’re going to have to work out all the circumferences and add them together. We’ll start by figuring out the relationship between the radii of consecutive circles. Here’s a quarter of the largest circle, the radius of which we’ll call $r_0$, and the next largest circle, the radius of which we’ll call $r_1$:

From this drawing, we can express the width in two ways and set them equal to one another:

Multiplying through by $\sqrt{2}$ and rearranging, we get

I want to turn this into a fraction with a 1 in the numerator, so I’ll multiply the top and bottom by an expression that will eliminate the square root in the numerator:

This relationship also holds for any two consecutive circles,

which means we can express the radius of the ith circle in terms of the radius of the largest circle:

So the sum of all the circumferences is $2\pi$ times the sum of all the radii:

Note that there’s only one circle with radius $r_0$, but two circles for all the other radii.

By the way, this expression is where it’s helpful to have the fraction inside the sum written with a 1 in the numerator. We know that

converges, so our fraction, which has a larger denominator, must also converge.

We’re nearly there. Recall that the gray square (the one that’s rotated 45°) has a side length of 1. That means

so the sum of the circumferences is

Now for a confession: I have always stunk at working out infinite series. Luckily, I can now lean on a computational cane. Here’s a Mathematica expression that will return the infinite sum:

Pi/Sqrt[2] (1 + 2 Sum[1/(3 + 2 Sqrt[2])^i, {i, 1, Infinity}])

The answer, as we know from doing it the easy way, is $\pi$.

If I didn’t have Mathematica, I’d probably set up a finite series for the expression without $\pi$,

and run out the calculations for different values of n to see where it converges. We can show the results as a table,

or as a plot,

Either way, going out ten terms is overkill—it’s obvious that the sum is converging to 1, which means the circumference sum is converging to $\pi$. You can, I guess, consider this numerical exercise as a check on Mathematica’s work. Or a check on the easy solution.

I used Emacs Lisp, mainly because I knew its calendar module had functions for converting between Chinese, Islamic, and Gregorian calendars. You may recall my date-convert script, which I first wrote back in 2008 and then updated a couple of years ago. Running it today, I got this output:

Gregorian:  Wednesday, February 18, 2026
      ISO:  Day 3 of week 8 of 2026
    Astro:  2461090
   Julian:  February 5, 2026
   Hebrew:  Adar 1, 5786
  Islamic:  Ramadan 1, 1447
  Chinese:  Cycle 78, year 43 (Bing-Wu), month 1 (Geng-Yin), day 2 (Gui-Hai)

My goal was to go through a few hundred years and print out (in Gregorian terms) the dates on which the first of Ramadan came one day after Chinese New Year. I’m very rusty in ELisp, so this probably isn’t very good code, but here it is:

#!/opt/homebrew/bin/emacs --script

(require 'calendar)
(require 'cal-islam)
(require 'cal-china)

;; Loop through 300 Islamic years, roughly centered on this year
(setq iy 1300)
(while (< iy 1600)
  ;; Get Ramadan 1 of the year as an absolute date
  (setq a (calendar-islamic-to-absolute (list 9 1 iy)))
  ;; Get the month and year of this date in the Chinese calendar
  (setq cdate (calendar-chinese-from-absolute a))
  (setq cmd (cdr (cdr cdate)))
  ;; Print the Gregorian date if Ramadan 1 is the day after Chinese New Year
  (if (equal cmd (list 1 2))
    (princ (concat 
             (calendar-date-string (calendar-gregorian-from-absolute a))
             "\n")))
  (setq iy (1+ iy)))

The ELisp calendar modules use the idea of an “absolute” date, which is a simple count of days in the Gregorian calendar. Day 1 in this absolute scale corresponds to January 1 in what would have been Year 1 if the Gregorian calendar had existed back then. This is called the proleptic Gregorian calendar. The absolute date is used as a way station when converting between calendars. You’ll see calls to functions with to-absolute and from-absolute in their names in a few places in the code.

As you can see in the output from date-convert, we’re currently in Year 1447 of the Islamic calendar. The while loop increments the iy variable from 1300 to 1600, a 300-year period roughly centered on this year. I get the first day of Ramadan (the ninth month) in each of those years and see if it matches up with the second day of the Chinese year. If so, it prints out the corresponding Gregorian date.

The format for dates in the Chinese calendar has four terms: Cycle, Year, Month, and Day. The cmd variable has just the month and year, which we get from the four-term date by applying the cdr function twice. cdr is one of the first Lisp functions you learn about, and I enjoyed pulling it out of my mental mothballs.

Here’s the script’s output:

Wednesday, February 3, 1897
Monday, February 11, 1929
Friday, January 31, 1930
Tuesday, February 6, 1962
Saturday, January 26, 1963
Wednesday, February 1, 1995
Wednesday, February 18, 2026
Tuesday, February 3, 2060
Saturday, January 22, 2061
Wednesday, January 28, 2093
Wednesday, February 16, 2124
Friday, February 11, 2157
Tuesday, January 31, 2158

These coincidences typically come 30+ years apart, but sometimes they occur in two consecutive years. The yesterday/today coincidence is the fourth time it’s happened in my life. I doubt I’ll be around for the next one; if I am, I’ll have my caretakers write a post about it.

My long-overdue icon complaint is about a CarPlay icon introduced in the fall of 2024 along with iOS 18. Apart from when an app is taking over the screen, there are two primary screens in CarPlay: the app icon view, which is sort of like the home screen on an iPhone,

and the split screen view, which is sort of like the old split view in iPadOS, but with more parts,

You switch between the two views by tapping the button in the lower left corner of the screen. The button with the 3×3 grid of little squircles is clearly a way to get back to the app icon view. Yes, it used to be a 2×4 grid, which actually matched the icon layout on my screen, but it’s still obvious what the button does. The single hollow squircle, on the other hand, just makes no sense. It doesn’t look anything like the split view screen it takes you to.

This wasn’t the case before the fall of 2024. Here’s what that button used to look like:²

Kind of obvious where this button takes you, isn’t it?

It’s not that I don’t know what the single hollow squircle button does—I’ve been using it for 16 months. The icon could look like Kurt Vonnegut’s drawing of an asshole in Breakfast of Champions and I’d soon work out what the button was for,³ but the purpose of an icon is to communicate, not just be a placeholder. There’s also parallelism to consider. The icon view button looks like the screen it leads to; so should the split screen view button.

It’s probably impossible to tell the upper echelon of Apple that it’s breaking revenue records in spite of its software design, not because of it. I hope the next regime knows better.

The inability of Claude and (especially) ChatGPT to extract data accurately from the chart discussed in the last post gnawed at me. It seemed like the sort of thing an LLM should be able to do pretty well, but Claude’s table of values needed some careful editing before I could use it. And ChatGPT just completely botched the job, even after several attempts to steer it right. I knew I could do a much better job in not much more time than I spent trying to get the LLMs to do it.

As a reminder, here’s the graph:

What I wanted was a CSV file with a column of dates (the x-values) and a column of floating point numbers (the y-values). One row for each of the 29 points.

I’ve done things like this in the past with OmniGraffle and AppleScript, so that’s how I approached the problem.

The first step was to get the x-values, which didn’t involve OmniGraffle or AppleScript. I opened the image in Preview, selected the text labels along the x-axis with TextSniper, and pasted the result into a new BBEdit window. Text Sniper had no trouble reading the rotated text, but it did have the values separated by space characters instead of line feeds. No problem; I just did a find/replace in BBEdit to get this:

2006-10
2007-03
2007-06
2008-01
2008-03
2008-05
2008-09
2008-12
2009-04
2009-06
2009-09
2009-12
2010-02
2010-03
2010-06
2010-11
2011-02
2011-05
2015-06
2017-03
2024-03
2024-07
2024-11
2025-04
2025-05
2025-07
2025-10
2025-11
2026-01

These dates are just months, and I figured it would be best for the plot to assume they were near the middle of each month, so I appended “-15,” to the end of each line. That set all the dates to the 15th of the month, and the comma prepared the file for pasting in the y-values:

2006-10-15,
2007-03-15,
2007-06-15,
2008-01-15,
2008-03-15,
2008-05-15,
2008-09-15,
2008-12-15,
2009-04-15,
2009-06-15,
2009-09-15,
2009-12-15,
2010-02-15,
2010-03-15,
2010-06-15,
2010-11-15,
2011-02-15,
2011-05-15,
2015-06-15,
2017-03-15,
2024-03-15,
2024-07-15,
2024-11-15,
2025-04-15,
2025-05-15,
2025-07-15,
2025-10-15,
2025-11-15,
2026-01-15,

Then came the real work. I pasted the image into a new OmniGraffle document with the scale set to “1 pt = 1 pt.” I did this because I knew that OmniGraffle’s AppleScript dictionary returns all coordinates and lengths in points with the origin at the upper left corner of the document. I then drew some thin-lined rectangles to get the y-coordinate of the horizontal axis and calculate the y-scale of the image.

A rectangle with its top edge along the horizontal axis told me that the y-origin of the plot was 581 points down from the top of the document. To get the scale of the plot, I drew another rectangle whose bottom edge was aligned with the negative sign in the “-4” label and whose top edge was aligned with the equivalent part of the “4” label. That rectangle was 512.6 points high, so the scale of the plot is

I then made a new layer called “Markers” and drew a diamond (OmniGraffle has a built-in diamond shape) sized to match the markers in the plot. By duplication and dragging, I put a diamond shape over every marker. Here’s what it looked like with every diamond selected:

If you zoom in, you’ll see that the diamonds are 26.4 points tall, which means that the center of each diamond is 13.2 points below its top edge. We’ll need this value in the AppleScript because when OmniGraffle is asked for the location of an object, it returns the coordinates of the top left corner.

Here’s another useful tidbit I’ve learned when using OmniGraffle’s AppleScript dictionary in the past: when you ask for every shape in a layer, the list of shapes is returned in the top-to-bottom order shown in the left sidebar. You may think this is obvious, but it isn’t. As you add shapes to a layer, each new shape appears in the sidebar above its predecessor. So the order of the items in the every shape list is the opposite of the creation order. The upshot of this is that to get the y-values of the diamonds in left-to-right order (to match their date order), I created them in right-to-left order.¹

Now it’s time to write and run the AppleScript that extracts the y-coordinates of the centers of the diamonds and scales them to match the plot. It’s pretty simple:

applescript:
 1:  set yValues to {}
 2:  set yOrigin to 581
 3:  set yOffset to 13.2
 4:  set yScale to 64.075
 5:  
 6:  tell application "OmniGraffle"
 7:    tell layer "Markers" of canvas 1 of document 1
 8:      set diamonds to every shape
 9:      repeat with d in diamonds
10:        set pt to (origin of d)
11:        set end of yValues to (yOrigin - (item 2 of pt) - yOffset) / yScale
12:      end repeat
13:    end tell
14:  end tell
15:  
16:  yValues

Line 1 initializes the list of y-values we’ll be building. Lines 2–4 set the values we established above. After the tell commands to establish that we’re focusing on the “Markers” layer, Line 8 creates the list of diamonds. Lines 9–12 loop through that list to get the location (origin) of each diamond and convert it to the value being plotted. The order in which the subtraction is done in Line 11 accounts for the fact that OmniGraffle’s coordinates increase as you go down but the plot’s coordinates increase as you go up.

Line 16 spits out the list of y-values in the Result section of Script Editor:

{1.777610453442, 2.105119526221, 2.417138303752,
-2.823376834196, -2.217843888773, 0.804769157205,
-3.225882114947, -2.315093559097, 1.802782567774,
2.308216918434, 3.517346715278, 3.011460781549,
2.606423024043, 3.211060498316, 4.212510467041,
4.018455838485, 4.315198697655, 4.018455838485,
3.316423039057, 2.512942396277, 1.803414490836,
1.203973154221, -0.507963600878, -0.304047453731,
-0.80360682595, -2.016491975871, -1.812215148741,
-2.521036825178, -2.2390063608}

That’s way more digits than is justified, but the extra digits don’t hurt anything. After turning each comma-space combination into a linefeed, I did a column paste to put the y-values after the dates. Adding a header line turned it into the CSV file I wanted for plotting:

Date,Hawk
2006-10-15,1.777610453442
2007-03-15,2.105119526221
2007-06-15,2.417138303752
2008-01-15,-2.823376834196
2008-03-15,-2.217843888773
2008-05-15,0.804769157205
2008-09-15,-3.225882114947
2008-12-15,-2.315093559097
2009-04-15,1.802782567774
2009-06-15,2.308216918434
2009-09-15,3.517346715278
2009-12-15,3.011460781549
2010-02-15,2.606423024043
2010-03-15,3.211060498316
2010-06-15,4.212510467041
2010-11-15,4.018455838485
2011-02-15,4.315198697655
2011-05-15,4.018455838485
2015-06-15,3.316423039057
2017-03-15,2.512942396277
2024-03-15,1.803414490836
2024-07-15,1.203973154221
2024-11-15,-0.507963600878
2025-04-15,-0.304047453731
2025-05-15,-0.80360682595
2025-07-15,-2.016491975871
2025-10-15,-1.812215148741
2025-11-15,-2.521036825178
2026-01-15,-2.2390063608

I still have the CSV file made by Claude. Let’s compare:

Claude’s values were off by only about 0.2 at worst, but recall that it originally included a spurious date and had the last seven y-values assigned to the wrong date. The “Claude” values shown above are after I figured out those obvious errors and corrected them.

An odd thing about Claude’s errors: they don’t show a consistent bias in either magnitude or direction. Like everyone who programs, I’m used to seeing output with incorrect numbers. (In my first draft of the AppleScript, I multiplied by yScale instead of dividing, which gave pretty wild results.) What I’m not used to is inexplicably wrong numbers—numbers that aren’t wrong in a predictable way.

At the risk of lengthening this post even further, here’s the graph with the AppleScript-derived values:

And here’s the Python code that created it:

python:
 1:  #!/usr/bin/env python3
 2:  
 3:  import pandas as pd
 4:  from datetime import datetime
 5:  import matplotlib.pyplot as plt
 6:  from matplotlib.ticker import MultipleLocator, AutoMinorLocator
 7:  from matplotlib.dates import DateFormatter, YearLocator, MonthLocator
 8:  
 9:  # Import the data
10:  df = pd.read_csv('warsh-applescript.csv', parse_dates=[0])
11:  x = df.Date
12:  y = df.Hawk
13:  
14:  # Create the plot with a given size in inches
15:  fig, ax = plt.subplots(figsize=(8, 5))
16:  
17:  # Add a line
18:  ax.plot(x, y, 'D-', color='#60150a', lw=3, ms=5)
19:  
20:  # Set the limits
21:  plt.xlim(xmin=datetime(2006,1,1), xmax=datetime(2026,12,31))
22:  plt.ylim(ymin=-4, ymax=5)
23:  
24:  # Set the major and minor ticks and add a grid
25:  ax.xaxis.set_major_locator(YearLocator(2))
26:  ax.xaxis.set_minor_locator(YearLocator(1))
27:  ax.xaxis.set_major_formatter(DateFormatter('%Y'))
28:  ax.yaxis.set_major_locator(MultipleLocator(1))
29:  ax.axhline(y=0, color='k', lw=.5)
30:  
31:  # Title and axis labels
32:  plt.title('Warsh commentary')
33:  plt.xlabel('')
34:  plt.ylabel('Monetary hawkishness')
35:  
36:  # Make the border and tick marks 0.5 points wide
37:  [ i.set_linewidth(0.5) for i in ax.spines.values() ]
38:  ax.tick_params(which='both', width=.5)
39:  
40:  # Reduce the whitespace around the plot
41:  plt.tight_layout()
42:  
43:  # Save as PNG
44:  plt.savefig('20260202-Warsh commentary via AppleScript.png', format='png', dpi=150)

Importing Pandas is overkill just to read a CSV file, but it’s more efficient of my time. The rest of the code is basically just my typical Matplotlib boilerplate with a few tweaks for dealing with the limits and tick spacing.

Did this take longer than having Claude return the CSV file? Of course it did, but it didn’t take much more than half an hour or so, equally divided between the OmniGraffle drawing and the AppleScript coding. And that half-hour was much more satisfying than arguing with a random number generator and then editing its work after losing the argument.

Also, because I’ve now written up the process (which took significantly longer than doing it), I have a method I can use with confidence in the future.

Krugman’s not to blame—at least not entirely—for how bad the plot is. It was given to him by Neil Dutta, who apparently had Claude assess the monetary hawkishness of Warsh’s statements, assign a number to it, and plot those numbers against the dates on which the statements were made. Here’s the result:

If you look along the horizontal axis, you’ll see immediately why this is an awful plot. The points are uniformly spaced horizontally, even though the spacing of the dates is far from uniform. Apparently, Claude considered entries like “2006-10” as categories rather than dates. Not especially intelligent of Claude or Dutta.

Krugman—who probably did’t want to go to the trouble of replotting the data—alerted his readers to the problem without being mean to Dutta:

If you look carefully at that chart, you’ll see that there’s a gap in the timeline for several years after Warsh was passed over for Fed chair during Trump’s first term.

Had the data been plotted correctly, you wouldn’t have to look carefully:

Because I didn’t want to go to too much trouble in making this plot, I didn’t adjust the labels on the horizontal axis the way I usually do. The labels are aligned with January 1 of each year.

You may also notice that the y-values in my graph aren’t a perfect match with the y-values in Dutta’s original. Using a “sauce for the goose” approach, I told Claude to assess Dutta’s plot and generate a CSV file with all the points. There were some serious errors in the resulting CSV—30 data points instead of 29 and 8 negative points at the right end of the graph instead of 7—but they were fairly easy to fix.¹ And since the relative hawkishness of Warsh’s commentary is a pretty soft number, I’m not worried about the individual values being off by a few tenths. The main thing was to get the dates plotted as they should be.

The little dots under the “horizon” represent the beginnings and endings of civil, nautical, and astronomical twilight, which is a nice addition to the plot. I assume the vertical axis has something to do with the Sun’s altitude angle, but since the plot gives no units, it must be an example of Bezos astronomy.

Scrolling down, we come to this odd graphic: the average sunrise and sunset times for each month of the year.

Given that I live in a state that switches between Standard Time and Daylight Saving Time, this is a troubling calculation. There’s no trouble making the calculation, of course: you just add up all the sunrise or sunset times and divide by the number of days in the month. And that’s clearly what Apple’s done. No, the trouble comes in March and November, the months when we switch from CST to CDT and back. What is the meaning of “average” when the individual values are measured differently?

On the second Sunday in March, sunrise and sunset suddenly become an hour later than they were, and the same thing happens in reverse on the first Sunday in November. Here in 2026, those days will be March 8 and November 1; in 2027, they’ll be March 14 and November 7. That the number of days we’re on CDT and CST in March and November changes from year to year makes the “averages” for those months even weirder.

After thinking about this for a while, I came to three conclusions:

1. It’s nice to have on hand a simple display of how sunrise and sunset change over the course of a year.
2. I may be the only person bothered by the way Apple presents this information.
3. I’ve already shown how I’d like to see it done.

A couple of years ago, I wrote a Python script that used Matplotlib and data from the US Naval Observatory to generate plots like this:

A graph like this wouldn’t work well on a phone because it’s wide instead of tall. But I figured it wouldn’t be too hard to redo it with the axes switched to give it a portrait format. I removed the various annotations because the location would be given in the Weather app. I also removed the “Hours of daylight” curve; without a 24-hour clock, I couldn’t cheat and treat the horizontal axis as both a time and a duration. I also got rid of the yellow and put everything in shades of gray to better match Apple’s aesthetic.

Apple would never include a plot with this many gridlines, but I couldn’t bring myself to get rid of them. They really help you track how the sunrise and sunsets change over the course of the year. Apple doesn’t want to scare its customers with complexity; when it feels the need to show detail, it puts it in a popup that appears when you tap inside the plot. Apple’s way is certainly cleaner looking, but I prefer seeing all the information at once.

Here’s the code that produced the plot above:

python:
  1:  #!/usr/bin/env python3
  2:  
  3:  import sys
  4:  import re
  5:  from dateutil.parser import parse
  6:  from datetime import datetime
  7:  from datetime import timedelta
  8:  from matplotlib import pyplot as plt
  9:  import matplotlib.dates as mdates
 10:  from matplotlib.ticker import MultipleLocator, FormatStrFormatter
 11:  
 12:  
 13:  # Functions
 14:  
 15:  def headerInfo(header):
 16:    "Return location name, coordinates, and year from the USNO header lines."
 17:  
 18:    # Get the place name from the middle of the top line
 19:    left = 'o  ,    o  ,'
 20:    right = 'Astronomical Applications Dept.'
 21:    placeName = re.search(rf'{left}(.+){right}', header[0]).group(1).strip()
 22:  
 23:    # If the place name ends with a comma, a space, and a pair of capitals,
 24:    # assume it's in location, ST format and capitalize the location while
 25:    # keeping the state as all uppercase. Otherwise, capitalize all the words.
 26:    if re.match(r', [A-Z][A-Z]', placeName[-4:]):
 27:      placeParts = placeName.split(', ')
 28:      location = ', '.join(placeParts[:-1]).title()
 29:      state = placeParts[-1]
 30:      placeName = f'{location}, {state}'
 31:    else:
 32:      placeName = placeName.title()
 33:  
 34:    # The year is at a specific spot on the second line
 35:    year = int(header[1][80:84])
 36:  
 37:    # The latitude and longitude are at specific spots on the second line
 38:    longString = header[1][10:17]
 39:    latString = header[1][19:25]
 40:  
 41:    # Reformat the latitude into d° m′ N format (could be S)
 42:    dir = latString[0]
 43:    degree, minute = latString[1:].split()
 44:    lat = f'{int(degree)}° {int(minute)}′ {dir}'
 45:  
 46:    # Reformat the longitude into d° m′ W format
 47:    dir = longString[0]
 48:    degree, minute = longString[1:].split()
 49:    long = f'{int(degree)}° {int(minute)}′ {dir}'
 50:  
 51:    return placeName, lat, long, year
 52:  
 53:  def bodyInfo(body, isLeap):
 54:    "Return lists of sunrise, sunset, and daylight length hours from the USNO body lines."
 55:  
 56:    # Initialize
 57:    sunrises = []
 58:    sunsets = []
 59:    lengths = []
 60:  
 61:    # Rise and set character start positions for each month
 62:    risePos = [ 4 + 11*i for i in range(12) ]
 63:    setPos = [ 9 + 11*i for i in range(12) ]
 64:  
 65:    # Collect data from each day
 66:    for m in range(12):
 67:      for d in range(daysInMonth[m]):
 68:        riseString = body[d][risePos[m]:risePos[m]+4]
 69:        hour, minute = int(riseString[:2]), int(riseString[-2:])
 70:        sunrise = hour + minute/60
 71:        setString = body[d][setPos[m]:setPos[m]+4]
 72:        hour, minute = int(setString[:2]), int(setString[-2:])
 73:        sunset = hour + minute/60
 74:        sunrises.append(sunrise)
 75:        sunsets.append(sunset)
 76:        lengths.append(sunset - sunrise)
 77:  
 78:    return(sunrises, sunsets, lengths)
 79:  
 80:  def dstBounds(year):
 81:    "Return the DST start and end day indices according to current US rules."
 82:  
 83:    # Start DST on second Sunday of March
 84:    d = 8
 85:    while datetime.weekday(dstStart := datetime(year, 3, d)) != 6:
 86:      d += 1
 87:    dstStart = (dstStart - datetime(year, 1, 1)).days
 88:  
 89:    # End DST on first Sunday of November
 90:    d = 1
 91:    while datetime.weekday(dstEnd := datetime(year, 11, d)) != 6:
 92:      d += 1
 93:    dstEnd = (dstEnd - datetime(year, 1, 1)).days
 94:  
 95:    return dstStart, dstEnd
 96:  
 97:  
 98:  # Start processing
 99:  
100:  # Read the USNO data from stdin into a list of lines.
101:  # Text should come from https://aa.usno.navy.mil/data/RS_OneYear
102:  usno = sys.stdin.readlines()
103:  
104:  # Get location and year from header
105:  placeName, lat, long, year = headerInfo(usno[:2])
106:  
107:  # Month information, adjusted for leap year if needed.
108:  monthNames = 'Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec'.split()
109:  isLeap = (year % 400 == 0) or ((year % 4 == 0) and not (year % 100 == 0))
110:  if isLeap:
111:    daysInMonth = [31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
112:  else:
113:    daysInMonth = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
114:  
115:  # Get sunrise, sunset, and sunlight length lists from body
116:  sunrises, sunsets, lengths = bodyInfo(usno[9:], isLeap)
117:  
118:  # Generate list of days for the year
119:  currentDay = datetime(year, 1, 1)
120:  lastDay = datetime(year, 12, 31)
121:  days = [currentDay]
122:  while (currentDay := currentDay + timedelta(days=1)) <= lastDay:
123:    days.append(currentDay)
124:  
125:  # The portion of the year that uses DST
126:  dstStart, dstEnd = dstBounds(year)
127:  dstDays = days[dstStart:dstEnd + 1]
128:  dstRises = [ x + 1 for x in sunrises[dstStart:dstEnd + 1] ]
129:  dstSets = [ x + 1 for x in sunsets[dstStart:dstEnd + 1] ]
130:  
131:  # Plot the data
132:  fig, ax =plt.subplots(figsize=(6,10))
133:  
134:  # Shaded areas
135:  plt.fill_betweenx(days, sunrises, sunsets, facecolor='gray', alpha=.5)
136:  plt.fill_betweenx(days, 0, sunrises, facecolor='black', alpha=.75)
137:  plt.fill_betweenx(days, sunsets, 24, facecolor='black', alpha=.75)
138:  plt.fill_betweenx(dstDays, sunsets[dstStart:dstEnd + 1], dstSets, facecolor='white', alpha=.5)
139:  plt.fill_betweenx(dstDays, sunrises[dstStart:dstEnd + 1], dstRises, facecolor='black', alpha=.16)
140:  
141:  # Curves
142:  plt.plot(sunrises, days, color='k')
143:  plt.plot(sunsets, days, color='k')
144:  plt.plot(dstRises, dstDays, color='k')
145:  plt.plot(dstSets, dstDays, color='k')
146:  
147:  # Background grids
148:  ax.grid(which='major', color='#ccc', ls='-', lw=.5)
149:  ax.grid(which='minor', color='#ddd', ls=':', lw=.5)
150:  
151:  # Vertical axis grid at month boundaries
152:  # ax.tick_params(axis='both', which='major', labelsize=12)
153:  plt.ylim(datetime(year, 1, 1), datetime(year, 12, 31))
154:  plt.tick_params(axis='y', length=0)
155:  m = mdates.MonthLocator(bymonthday=1)
156:  mfmt = mdates.DateFormatter('')
157:  ax.yaxis.set_major_locator(m)
158:  ax.yaxis.set_major_formatter(mfmt)
159:  ax.yaxis.set_inverted(True)
160:  
161:  # Month labels inside the plot in white letters
162:  for m in range(12):
163:    middle = sum(daysInMonth[:m]) + daysInMonth[m]//2
164:    ax.text(.5, days[middle], monthNames[m], fontsize=12, color='w', ha='left', va='center')
165:  
166:  # Horizontal axis labels formatted like h:mm
167:  plt.xlim(0, 24)
168:  xmajor = MultipleLocator(4)
169:  xminor = MultipleLocator(1)
170:  ax.xaxis.set_major_locator(xmajor)
171:  ax.xaxis.set_minor_locator(xminor)
172:  plt.xticks(ticks=[0, 4, 8, 12, 16, 20, 24], labels=['mid', '4:00', '8:00', 'noon', '4:00', '8:00', 'mid'])
173:  
174:  # Tighten up the white border and save
175:  fig.set_tight_layout({'pad': 1.5})
176:  plt.savefig(f'{placeName}-{year}.png', format='png', dpi=150)

It’s a modification of the script given in my post from a couple of years ago. The main difference, apart from the color changes, is that instead of using Matplotlib’s fill_between function, I used the similar fill_betweenx function in Lines 135–139. Because the axes were switched, I needed to fill between vertical curves instead of horizontal curves.

The other unusual thing I did was use Matplotlib’s text function in Lines 161–164 to put the month labels inside the graph instead of along the left edge. That made the plot more compact. Because months are intervals of time, I centered the labels within their intervals. Apple (along with the rest of the world) puts labels like this at the start of each interval, but I refuse. Just because graphing software makes it easiest to do it that way doesn’t make it right.

Overall, I prefer the horizontal graph with the yellow sunlight hours, but it was fun figuring out how to make an alternative.

For weeks—maybe months, time has been hard to judge this past year—Trump has been telling us that he’s worked out deals with pharmaceutical companies to lower their prices by several hundred percent. Commentators and comedians have pointed out that you can’t reduce prices more than 100% and pretty much left it at that, suggesting that Trump’s impossible numbers are due to ignorance.

Don’t get me wrong. Trump’s ignorance is nearly limitless—but only nearly. I’ve always thought that he knew the right way to calculate a price drop; he did it the wrong way so he could quote a bigger number. And that came out in yesterday’s speech:

The embedding code is supposed to start the video just after the 47-minute mark. If it doesn’t, that’s where you should scroll to.

If you can’t stand listening to him for even 15 seconds, here’s what he said:

Under my most-favored nation policy for drug prices, the cost of prescription drugs is coming down by up to 90%, depending on the way you calculate. You could also say 5-, 6-, 7-, 800%. There are two ways of figuring that.

Apparently, Trump or his staff decided that this particular audience wouldn’t swallow his usual percentage calculation, so he decided to do it the right way, even though he went on to defend his usual method. Trump has testified that his net worth is whatever he feels it should be on a given day, so why wouldn’t there be more than one way to calculate a price drop?

It’s hard to know what goes on in Donald Trump’s head, but I’m confident of two things:

1. He knows that price increases and decreases are opposites. Therefore, if a price jump from $10 to $100 is a 900% increase, then a price drop from $100 to $10 must be a 900% decrease. It’s just logic.
2. If you were selling him something and agreed to lower your price from $100 to $10, he would call it a 90% decrease, not a 900% decrease. If he were giving you the same discount (ha!), it would be a 900% decrease. The numbers he uses are whatever sound best to him at the time.

Of course, the key thing about Trump’s deals with drug companies isn’t how percentages are calculated; it’s whether these deals will have any real effect.

My favorite reference for this phenomenon is this 1996 paper by Jeffrey R. Gordon of the Building Research Council at the University of Illinois. It’s entitled “An Investigation into Freezing and Bursting Water Pipes in Residential Construction,” and it goes through the testing that the BRC did on behalf of the Insurance Institute for Property Loss Reduction.

Why do I have a favorite reference for burst pipes? I used to get hired by insurance companies to investigate burst pipes and the subsequent damage in high-end residences. When the pipe failed in a heated area, it was nice to have this paper to back up my explanation of how freezing in one part of a pipe can lead to failure in another. Also, the report is quite easy to read. There’s not a lot of jargon, and you don’t need much scientific or engineering background to understand it.

Here’s Figure 15 from the report, which graphs the data collected during the testing of a 3/4″ copper pipe running through an unheated attic. The pipe was instrumented with thermocouples to capture its temperature at three locations and a pressure gauge to capture the water pressure inside it. The red annotations are mine. As you can see, the pressure rose to about 4,000 psi, at which point the pipe bulged—that’s the drop in pressure as the pipe increased in diameter and decreased in wall thickness—and then burst.

The best explanation of what happened in the test—and what commonly happens in real-world pipe bursts—comes from the report itself:

This shows the central, and often least understood, fact about burst water pipes: freezing water pipes do not burst directly from physical pressure applied by growing ice, but from excessive water pressure. Before a complete ice blockage, the fact that water is freezing within a pipe does not, by itself, endanger the pipe. When a pipe is still open to the water system upstream, ice growth exerts no pressure on the pipe because the volumetric expansion caused by freezing is absorbed by the larger water system. A pipe that is open on one end cannot be pressurized, and thus will not burst.

Once ice growth forms a complete blockage in a water pipe the situation changes dramatically. The downstream portion of the pipe, between the ice blockage and a closed outlet (faucet, shower, etc.) is now a confined pipe section. A pipe section that is closed on both ends can be dramatically pressurized, water being an essentially incompressible fluid. If ice continues to form in the confined pipe section, the volumetric expansion from freezing results in rapidly increasing water pressure between the blockage and the closed outlet. As figure 15 shows, the water pressure in a confined pipe section can build to thousands of pounds per square inch.

Read that second paragraph again. It’s really a perfect explanation of how, for example, a pipe or joint under a bathroom sink can fail even though that part of the pipe was never exposed to freezing temperatures. It’s the ice buildup in the pipe elsewhere—typically in an unheated area on the other side of the drywall—and the continued growth of ice in the isolated zone between that blockage and the faucet at the sink that leads to a huge increase in pressure. The pipe will fail at whatever point is weakest within that zone.

Which leads to some common advice given when temperatures are going to drop.

• For sinks up against an outside wall, leave the cabinet doors open so the warm air of the house gets a chance to circulate around the pipes. You want them to get as much exposure to warm air as possible so they can conduct that heat to the colder parts on the other side of the drywall.
• Open faucets that are against an outside wall and let them drip. I’ve never done this because I added extra insulation around and on the cold side of my pipes many years ago, but it can help. Not, as some people say, because moving water doesn’t freeze (have they never seen a river frozen over?) but because a slightly open valve prevents the buildup of pressure shown in Figure 15. As the report says, “A pipe that is open on one end cannot be pressurized, and thus will not burst.”

At the end of last week’s belaying post, I said we’d look into the condition in which the climber and belayer don’t weigh the same. And we will. But first, I want to talk about stretchy ropes.

One of my assumptions in the last solution was that the rope connecting the climber and the belayer was inextensible. Now, no ropes are truly inextensible, but I thought it was a reasonable assumption, at least for a first-pass solution. But Rob Nee (via Mastodon), Dirk KS (also via Mastodon), and Kenneth Prager (via email) thought the extensibility of climbing ropes was worth discussing. Dirk KS even sent me a link to the Samson Rope Technologies page that includes this nice graph of its ropes’ compliance:

(If you’re an engineer, you’re used to seeing load-deflection curves with the load on the vertical axis and deflection on the horizontal axis. Be aware that this one is drawn the opposite way.)

I can certainly understand why climbers consider their ropes’ compliance to be important: it makes for a more gentle stop at the end of a fall. For our purposes, what’s important is the potential energy absorbed by the rope as it stretches. If the rope is linearly elastic, the potential energy in a rope that extends by an amount x from its natural length is

where k is the stiffness of the rope and F is the tension. The Samson graph tells us that their ropes are linearly elastic for loads of up to about 400 lbs, so let’s use this equation and see where it gets us.

You may recall that Prof. Allain did some motion analysis of the video and came to the conclusion that the climber was about 7.2 m above the belayer when he started his fall. I took this value and some scaling of the video frames I showed in the previous post to estimate the following values:

• Length of rope (L): 24 ft.
• Height of loop (h): 18 ft.
• Initial distance of climber above loop (d): 6 ft.

I’ll also assume the climber and belayer each weigh 150 lbs. These are rough, rounded estimates because I don’t feel greater precision is warranted.

When the climber and belayer come to a halt and are just hanging there, the tension in the rope is equal to each man’s weight: 150 lbs. According to the Samson chart, the more compliant ropes will stretch about 0.75% under this load, which means the rope will stretch

So the elastic energy in the rope is

The gravitational potential energy lost during the initial drop of twelve feet by the climber (which is when the rope first becomes taut) is

The energy that goes into stretching the rope is small potatoes compared to this, so it’s not unreasonable to ignore it in our energy accounting system.

Let’s move on to consider unequal weights. We’ll say the climber has a mass of m, as before, but now the mass of the belayer is βm. As before, the potential energy before the climber falls is

and there’s no kinetic energy: $K_0=0$

When the rope becomes taut (we’re assuming an inextensible rope again), the potential energy has dropped to

so the kinetic energy must be

From this point on, the rope keeps climber A and belayer B moving in concert, so

and the change in potential energy will be

Ignoring frictional losses, the change in kinetic energy will be

Now we have three situations to consider:

1. $\beta <1$ means $\mathrm{\Delta }K>0$ and (without friction) the movement never stops.
2. $\beta =1$ means $\mathrm{\Delta }K=0$ and (without friction) the movement never stops.
3. $\beta >1$ means $\mathrm{\Delta }K<0$ and the movement might stop, at least momentarily, even without friction.

The second condition is what we covered last time, so I won’t repeat that.

For the third condition, where the belayer weighs more, the system might stop momentarily with the belayer at his highest point and the climber at his lowest, even if there’s no friction in the system. If and where this happens depends on the specific values of β, h, and d. The key concern is whether the climber hits the ground before this momentary stop occurs.

To me, the first condition is the most interesting. It says that the system won’t stop if the belayer weighs less than the climber. In fact, if there’s no friction in the system, the climber would go down to the ground even if the two started hanging statically at the same elevation. But the fact is, lighter belayers can safely control heavier climbers (Kenneth Prager told me he often belays his son, who outweighs him by over 50 lbs). You can see that in this video from the American Alpine Club:

In this video, the rope is running through several carabiners; in the subject video, it appears to be running through just one. Either way, this way of using the friction of a rope running over a stationary curved surface to control movement has been known for ages. It’s called the capstan problem, and it’s covered in the friction section of most elementary engineering mechanics classes.

At this point, longtime readers are expecting me to go through the capstan problem, but really longtime readers know I already did that back in 2010. Oddly enough, that post was inspired by my acting as a belayer at my younger son’s school while his fourth-grade gym class did a rock-climbing unit. That son will be visiting me this weekend; he’s coming into town on a business trip for client meetings in the area early next week. I’m still trying to figure out how a fourth-grader has clients.

What prompted this post was being chastised by my phone this morning for getting only about an hour of sleep last night. This was unwarranted. What actually happened was that I fell asleep for maybe an hour and a half while reading last night. When I woke up, I took off my watch, put it on the charger, and got ready for bed. I slept pretty well.

I could take this opportunity to say that since my watch knew damned well that it was on the charger instead of my wrist overnight, it should have shared that information with my phone and told it not to scold me. But my expectations of Apple software have been lowered to the point where that wasn’t even a blip on my radar. It did remind me, though, that I’ve been meaning to write about errors the Apple Watch makes in measuring resting heart rate.

Note the word resting. I think the watch’s heart rate monitor itself does a good job. Whenever I’ve checked its reading against a manual pulse count, the two are very close—close enough that the difference could be a real minute-to-minute variation. But the resting heart rate is supposed to be… well, here’s what Apple says in the Health app:

Your resting heart rate is the average heart beats per minute measured when you’ve been inactive or relaxed for several minutes. A lower resting heart rate typically indicates better heart health and cardiovascular fitness. An increase in resting heart rate at times may be normal and expected, such as during an illness or a pregnancy.

You may be able to lower your resting heart rate over time by staying active, managing your weight, and reducing everyday stress. Resting heart rate does not include your heart rate while you’re asleep and is validated for users over the age of 18.

Emphasis mine.

So the resting heart rate is based not only on the watch’s heart rate monitor, which, as I just said, is quite good, but also on its assessment of whether you’re sleeping or not. Like Santa Claus, the Apple Watch sees you when you’re sleeping and knows when you’re awake. Or does it?

I’ve had an Apple Watch since the Series 3, and over most of that time I’ve taken the watch off when I go to bed and let it charge overnight. In July of 2024, though, I started a diet program to control my Type 2 diabetes. The diet program included an app that wanted the sleep data from my watch, so I started wearing it overnight.

I left the program about a year ago because my insurance changed and my new plan wouldn’t pay for it. Don’t worry, I’m still eating right and my A1C has continued to go down. And I kept wearing my watch overnight because I was in the habit of doing so.

Then came iOS and watchOS 26 this fall and with them came the Sleep Score, which was on by default after the upgrade. My Sleep Scores stunk because I am a gentleman of a certain age, and I get up to pee overnight—sometimes twice. This was annoying, so my first reaction was to remove the Sleep Score from the Pinned section of the Health app’s Summary. But then I thought, Why am I still wearing my watch overnight? Doing so means I have to find a time during the day to charge the watch, and it’s much easier to just charge it overnight and wear it all day.

So I started wearing my watch overnight in July of 2024 and went back to not wearing it overnight in November of 2025. Let’s take a peek at my resting heart rate for the six-month periods surrounding those months.

Oh, look! My heart rate went from the mid-50s down to the high-40s in July 2024 and from the high-40s to the low-50s in November 2025. What a coincidence!

What really happened, of course, was that the watch was treating some of my sleep time as awake-but-relaxed time and was counting my heart rate during those periods as resting. The Apple Watch is not as perceptive as Santa Claus.

So if you’ve always worn your watch overnight because you like getting sleep statistics from it, recognize that it may be giving you lower readings for your resting heart rate. If that matters to you, you may want to sleep without your watch for a while to see if you get a different resting heart rate.