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

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

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

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

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

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

In its continuing attempt to teach us how calendars work, Scientific American has an article (Apple News link) up today that goes through Gauss’s algorithm for calculating the date of Easter. The article was written by Manon Bischoff, who also wrote the Friday the 13th article I covered a few weeks ago.

There are a few small mistakes in the article: one computational and two definitional. Let’s take a look at them.

The computational error comes in the calculation of the intermediate value p. The article says

where the topless brackets mean the floor function, the integer less than or equal to what’s inside the brackets. The correct equation is

In both equations, k is

i.e., the first two digits of the year (at least until we get to the year 10,000).

In giving the wrong equation for p, Bischoff is following Gauss himself. In the original presentation of his Easter algorithm, Gauss gave the same simple formula as Bischoff, but he corrected it several years later. Why Bischoff is still using the wrong equation two centuries later is anyone’s guess.

Actually, I can guess. Maybe Bischoff’s using the wrong formula for p because it’s simpler and the error won’t manifest itself until the year 4200 (!). Here’s a quick Python script to see the centuries, starting in the 1600s, for which the simpler formula is wrong:

python:
for k in range(16, 60):
  if k//3 != (13 + 8*k)//25:
    print(f'Century {k*100} gives the wrong value')

The output is

Century 4200 gives the wrong value
Century 4500 gives the wrong value
Century 4800 gives the wrong value
Century 5100 gives the wrong value
Century 5400 gives the wrong value
Century 5700 gives the wrong value

I think we can live with a mistake that won’t rear its head for over 2000 years.

I’m less inclined to overlook the definitional errors in the article’s early paragraphs. This one:

For those who celebrate it, tracking what day the holiday Easter takes place on can be a challenge. According to Christian religious traditions, Easter Sunday falls on the first Sunday following the first full moon after the vernal equinox.

And this one:

[T]he vernal equinox, or start of spring, is fixed as March 21. If a full moon occurs on that exact day, March 22 becomes the earliest possible calendar date for Easter Sunday. According to the lunar calendar, the latest possible date for a full moon after March 21 is April 18. That means Easter Sunday never falls later than April 25.

While it’s true that the idea behind the date of Easter is to be “on the first Sunday following the first full moon after the vernal equinox,” when it comes to determining Easter, both the equinox and the lunar cycle are estimated—they aren’t based on accurate astronomical calculations or observations.

First, let’s look at the vernal equinox.¹ One need only think back a couple of weeks to realize that it isn’t “fixed as March 21.” The most recent equinox was on March 20, as were 58 of the 66 vernal equinoxes I’ve lived through. March 20 is by far the most common date for the true vernal equinox. The Church fathers who set the date of Easter used March 21 as an approximation because it made the calculation simple and resulted in Easters more or less when they thought they should be.

Similarly, they used the Metonic cycle—with some occasional adjustments—to estimate when full moons would occur. There are almost exactly 235 lunar months in 19 years, a fact you can use to calculate a good estimate of when full moons occur.² But this is an average, and because lunar months vary in length, the date of a calculated full moon doesn’t always fall on the date of an actual full moon. (There’s also a slow drift that has to be accounted for.)

So although the date of Easter is guided by astronomical events, it isn’t determined by them. As it happens, this year the vernal equinox was, as we said, on Friday, March 20, and the following full moon was on Wednesday, April 1. So having Easter Sunday on April 5 works out both astronomically and algorithmically. But in 2019, that wasn’t the case. The vernal equinox was on Wednesday, March 20; the following full moon was on Thursday, March 21; but Easter Sunday was celebrated on April 21, not March 24.

To recap, my January complaint was that although I could create a complication that looked like it would start a 30-second timer when tapped, that complication actually required a second tap on a smaller button to start it—a stupid way to implement the feature. As of 26.4, the stupidity has been removed. Now the timer starts immediately when you tap the complication.

If you’d like a quick way to set a specific timer on your watch, press and hold on your watch’s home screen, tap the Edit button, and then swipe (if necessary) to get to the complications screen. Tap the complication you want to change to a Timer, scroll through the list, and choose Timers. At this point, you will be given the option to choose either a generic timer complication—one that just opens the Timers app—or one set to one of the specific times you’ve created in the Timers app.

Choose the one you want and go back to your home screen. Now you have a specific timer complication that works the way it should.

(Aside: I wanted a 30-second timer in January because I was doing physical therapy stretching exercises then that were supposed to be held for 30 seconds. I’m not doing those exercises anymore, so I made a 3-minute timer for tea.)

Thanks to Dan for telling me about this. I had given up on this type of complication and wouldn’t have thought to look for the improvement.

Another improvement in 26.4—one that’s sort of mentioned in the release notes—is that you no longer have to tap the small arrow button to start a workout. You can also tap anywhere in the big area around the exercise icon above the three bottom buttons on the Workouts screen. And you don’t have to wait for the arrow button to slowly animate into view.

I bitched about the previous behavior—prompted by a Greg Pierce complaint—in December. It’s almost as if Apple is listening now.

I’ve been working my way slowly through Reingold and Dershowitz’s Calendrical Calculations. This week I hit Chapter 11 on the Mayan and Aztec calendars and came across a notation for modulo arithmetic that wasn’t familiar to me.¹ I figured I’d write about it here on the off-chance that any of you would find it interesting. Also, to make it stick in my head a little better.

The notation came up in the section on the Haab calendar, a sort of solar calendar that the Mayans used along with the Tzolk’in and Long Count calendars. The Haab calendar has 18 months of 20 days each and then a 19th sort-of-month with just 5 days. There’s no year number in the Haab calendar, so there’s no way to convert directly from the Haab calendar to other calendars. But there is a way to get a date in another calendar that’s on or nearest before a given Haab date.

Reingold and Dershowitz use a “fixed” or “RD” calendar as their way station between all the calendars. It’s a single day number that counts up from what would have been January 1 of the Year 1 in the Gregorian calendar if the Gregorian calendar had existed back then. In this system, 0001-01-01 is Day 1 and today, 2026-03-27, is Day 739,702.

The function that finds the closest given Haab date on or before a given fixed date is called mayan-haab-on-or-before, and it’s defined this way in the text:

What’s odd about the modulo notation in this definition is that the thing after “mod” isn’t a divisor, it’s an interval: the half-open interval between date (inclusive) and date – 365 (exclusive).

Here’s how R&D define this interval modulus, both in Chapter 1 of Calendrical Calculations and in this ACM paper:

As long as the two ends of the interval aren’t identical, the answer will lie in the range $[a..b)$. This notation is helpful in shifted modulo operations like the one in mayan-haab-on-or-before because it explicitly tells you the range of answers you’ll get. The idea is that the resulting fixed date will be anywhere from 0 (inclusive) to 365 (exclusive) days before the given date.

(The normal modulo notation, $n\mathrm{mod}m$, could be written as $n\mathrm{mod}[0..m)$, although this doesn’t seem particularly helpful.)

Note that in mayan-haab-on-or-before, the interval goes backward, which means the divisor in the standard mod function is a negative number: –365. If you’re implementing this function in a programming language, you have to make sure that using a negative divisor in your language’s mod will give you a negative answer. This means that mod must have a floored definition. The mod function in Lisp, which R&D are using, and the % operator in Python, which I’m using as I reimplement R&D, both use the floored definition.

I mentioned earlier that the 19th month of the Haab calendar is an oddball because it has only 5 days. As it happens, today is smack in the middle of that 19th month, which is called Wayeb or Uayeb, depending on whose transliteration you use.

Another odd thing about the Haab calendar—something that computer programmers must love—is that the day numbers within a month start at 0, not 1. So Monday, which is the start of the next Haab cycle, will be 0 Pop, Pop being the name of the first Haab month.

Near the end of the article, Rossignol says

We have yet to determine exactly which commands trigger the warning, which does not always appear.

I updated to 26.4 today and tried to trigger the warning. Since rm -rf is generally considered dangerous, I created some files I could try it out on.

Here are the commands I used in Terminal to create five new files, named test1.txt through test5.txt, in a folder named test and fill them with some nonsense text:

$ mkdir test
$ touch test/test{1..5}.txt
$ pbcopy <<END
> Same continent also, pre-occupation has probably played a more marked
influence; thus I can understand how it may be said, to be striving to the 
feral animals of South America) the black bear was seen by Hearne swimming 
for hours with widely open through an internal force beyond the other 
completed cells. It must suffice for our profound ignorance on the variations 
which have been.
> END
$ for f in test/*; do pbpaste >> $f; done

The nonsense text in the here-document was generated on the fly using my Dissociated Darwin script. I used to call it via TextExpander; now it’s called via Typinator, but the process is the same.

I then created a simple HTML file with the command rm -rf test in its body and uploaded it to my server. Since websites were mentioned in the warning as a source of dangerous commands, I figured copying the command from an external site would be the most likely way to trigger the warning.

I aimed Safari at the file’s URL, copied the command, switched back to Terminal, and pasted. No warning popped up, and I was able to execute the pasted command and delete the folder and files with no trouble.

OK, let’s try something a little more convoluted. After recreating the test folder and files, I made a file named dangerous.txt and put it on my server. Its contents were simply rm -rf test. I then added this command to the HTML file described above:

curl https://leancrew.com/dangerous/dangerous.txt | bash

Surely, I thought, a command that pipes the contents of some random file on the internet into bash for execution would be worth warning about. Nope. I copied the curl command from Safari, pasted it into Terminal, and hit Return. No warning from macOS and my test folder and files disappeared again.

My feelings about this have gone from “I hope Apple doesn’t make it impossible for me to work the way I normally do” to “Looks like Apple isn’t going overboard on the protection” to “Is there any protection here at all?”

Maybe there’s some setting on my system I changed long ago that’s now bypassing the warning. If so, I’d like to know what it is. Or maybe I just haven’t hit a high enough danger level yet. Which seems wrong.

Jason’s primary complaint about the Studio Display isn’t its high price or how little it’s improved over the 2022 version. It’s that the base stand—the one you get for $1600—has no height adjustment. To get the ergonomic benefit of height adjustment, you need to buy either the VESA mount adapter (and an arm if you don’t already have one) or the exquisite height-adjustable stand, which is a $400 addition.

It’s hard to argue with Jason when he says this:

Apple claims it’s a champion of accessibility. But in my opinion, part of accessibility is ergonomics. Different people need displays at different heights, and we are all shaped differently. Apple’s continued insistence on shipping displays and iMacs that aren’t height-adjustable by default is frustrating. You spend all this money on a pricey Apple display and then, what, put it on an old dictionary? Meanwhile, even the cut-rate competition offers height adjustments.

The “old dictionary” comment reminded me that in the days of CRT monitors, I—and many of the people I worked with—used the CRC Handbook of Chemistry and Physics to bring our monitors up to the proper height. We all agreed it was the best use we’d ever gotten out of that book.

And that experience my friends and I had with the CRC Handbook points to an important fact about monitor height adjustment: for most people, it’s a set-it-and-forget-it feature. You get your monitor to a height that works well with your desk setup, and you don’t change it for ages. The smooth fingertip control Apple provides with its upgraded stand—while undoubtedly useful for some—isn’t the kind of ergonomic help that most customers need.

What Apple’s doing here is the opposite of what it does on the software side. Most Apple apps are built to be good enough for the great bulk of its users. People who need more—in a calendar, a mail client, a to-do manager, a spreadsheet, a word processor, and so on—go to third-party apps to get those extra features.

This has served both Apple and its customers well. Even those of us who consider ourselves power users aren’t power users across the whole gamut of computing. We use a mix of basic and advanced apps to match our needs. Apple doesn’t have to stay on the cutting edge of all its many software products, and we get free apps that handle a lot of what we do.

Maybe Apple thinks its basic stand has been designed to hit that sweet spot for the vast majority of its users. Maybe they’ve spent considerable time and money on studies of desks and chairs and torsos and have come up with a single monitor height that’s “just fine.” I hope not, because that money would’ve been better spent on a simpler and less beautiful height-adjustable stand.

I’ve been working my way through the fourth edition of Reingold and Dershowitz’s Calendrical Calculations, and I want to talk about something I learned.

It’s a simple inequality that initially appears in the first chapter of the book and gets used several times thereafter. Here it is:

It’s first presented as a way to figure out how leap years are distributed. In some calendars—not the Gregorian—there’s a repeating cycle of $c$ years in which $\ell$ years are leap years. If the leap years are distributed as evenly as possible, then the years in which $y$ satisfies the inequality are the leap years. The $\mathrm{\Delta }$ is a sort of offset that determines the position within the cycle associated with Year 0, and the $\mathrm{mod}$ operator represents modulo division. In Python, that’s the % operator.

It’s helpful to look at examples. Let’s say we have a 7-year cycle with 2 leap years and 5 normal years in each cycle. The leap years have to be either 3 or 4 years apart. Here’s an example showing three cycles:

                       1 1 1 1 1 1 1 1 1 1 2 2
Year 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type N N N L N N L N N N L N N L N N N L N N L

For this, $c=7$, $\ell =2$, and $\mathrm{\Delta }=0$. You can plug the values into the inequality to show that it’s satisfied for years 4, 7, 11, 14, 18, 21, and so on.

Here’s a similar example. The only difference is the offset. In this case, $\mathrm{\Delta }=2$, and the leap years are years 2, 5, 9, 12, 16, 19, and so on.

                       1 1 1 1 1 1 1 1 1 1 2 2
Year 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type N L N N L N N N L N N L N N N L N N L N N

A practical example of this formula is with the Hebrew calendar. It has a 19-year cycle ($c=19$) with 7 leap years ($\ell =7$), and the offset is 11 years ($\mathrm{\Delta }=11$). The current year is 5786, for which

so this is not a leap year. But for next year,

so it is a leap year and will have 13 months instead of 12. You can confirm this on any number of websites; the key is to note that 5787 has both an Adar I and an Adar II.

The Gregorian calendar has a 400-year cycle with 97 leap years, but those leap years are not distributed as evenly as possible, so the formula can’t be used. If it had been used, we’d have leap years typically every fourth year but occasionally every fifth year. Pope Gregory and his people must’ve thought that would be too tricky to deal with.

Surprisingly (to me, anyway), Reingold and Dershowitz do use this formula with the Gregorian calendar, but they use it with months instead of years. Think of the months in the Gregorian calendar as being either short or long. In a year, there are 5 short months and 7 long months, and they’re distributed like this:

                          1 1 1
        1 2 3 4 5 6 7 8 9 0 1 2
Month   J F M A M J J A S O N D
Length  L S L S L S L L S L S L

The positions of the long months correspond to our inequality with $c=12$, $\ell =7$, and $\mathrm{\Delta }=11$. Plug in those values, and you’ll see that the long months are 1, 3, 5, 7, 8, 10, and 12.

To calculate the day number within a year, it’s usually easiest to calculate the number of days in the preceding months and then add the day number within the current month. Today is March 15, so it’s Day $(31+28)+15=74$ of the year.

Instead of looping through the lengths of the preceding months, R&D use a formula based on our inequality to count the number of long months before the current month. That formula is

where the brackets without tops represent the floor function, i.e., the integer equal to or just below what’s inside the brackets.

Plugging in our values for $c$, $\ell$, and $\mathrm{\Delta }$ and doing some algebra, we get

This is the number of long months in the year before the current month $m$.

If February had 30 days, the number of days in the months before the current month would be

So to get the (Gregorian) day of the year, R&D calculate the day number as if February had 30 days and then subtract (if necessary) to account for February’s deficiency. In Python, the code looks like this:

python:
def day_of_year(year, month, day):
  year_day = (367 * month - 362) // 12 + day
  if month <= 2:
    return year_day
  elif leap_year(year):
    return year_day - 1
  else:
    return year_day - 2

where I’m assuming we already have a Boolean function leap_year to determine whether it’s a leap year or not. That’s not necessarily the most obvious code in the world, but it makes sense if you’ve gone through the derivation.

One last thing. Reingold is the co-author of a paper in which our inequality is connected to Euclid’s algorithm for calculating the greatest common divisor and Bresenham’s algorithm for plotting lines on bitmaps. Which is pretty cool.

and this true but overstated conclusion:

In other words, the 13th of a month will be a Friday more times than any other day of the week.

Well, yes, if you live to be 400 years old, you’ll see one more Friday the 13th than Wednesday the 13ths or Sunday the 13ths. Kind of a weird thing to focus on, though. I’m guessing you’ll have other worries by then.

But I shouldn’t be so snarky. A few years ago, I wrote a post that calculated the same set of Fri13 counts for a 400-year Gregorian cycle. I did the calculations in Mathematica and (of course) showed the code. Today, I did the same thing in Python,

python:
 1:  #!/usr/bin/env python
 2:  
 3:  from datetime import date
 4:  
 5:  f13s = [0]*7
 6:  for y in range(1800, 2200):
 7:    for m in range(1, 13):
 8:      wd = date(y, m, 13).weekday()
 9:      f13s[wd] += 1
10:  
11:  print(f13s)

and got a result of

[685, 685, 687, 684, 688, 684, 687]

for Monday through Sunday. This also matches the SciAm table.

Those of us who are alive now (and have realistic longevities) won’t live through any non-leap century years. For us, the calendar has and will repeat every 28 years (1461 weeks), and over every 28-year period in our lives, there will be 48 Fri13s, the same as the number of Mon13s, Tue13s, Wed13s, and so on.

Of course, few of us live exactly a multiple of 28 years. Personally, I’ve lived through 113 Fri13s so far, which is just under the number of Sun13s I’ve seen (114). So I’ve been lucky?

In a Friday the 13th post from way back in 2012, I talked about how Fri13s repeat within years because the number of days in certain month sequences is a multiple of 7. So if there’s a Fri13 in April, there will be another in July because

Apr + May + Jun
30  + 31  + 30  = 91

which is 13 weeks. The last time that happened was in 2018.

Similarly, if there’s a Fri13 in September, there will also be one in December because

Sep + Oct + Nov
30  + 31  + 30  = 91

That pair of Fri13s last happened in 2024.

There’s also an 8-month sequence that adds to a multiple of 7:

Mar + Apr + May + Jun + Jul + Aug + Sep + Oct
31  + 30  + 31  + 30  + 31  + 31  + 30  + 31  = 245

So there will be another Fri13 in November of this year.

The sequences above happen every year. In non-leap years only—this year, for example—a Fri13 in February will be followed by one in March. In leap years only, a Fri13 in January will be followed by one in April. That last happened in 2012.

I covered all these repeated Fri13s in that 2012 post. Today, I learned of a new repeat that spans certain year boundaries. If there’s a Fri13 in December of a non-leap year that’s followed by a leap year, there will be a Fri13 in March of that following year. That last happened in December of 2019 and March of 2020.

Superstitious or not, you have to admit March of 2020 was pretty unlucky.

So Apple has done the work to put two USB-C ports on the Neo—and those ports reveal a bit more of the struggles Apple had in building this computer. Both of the USB-C ports will let you charge (which is good, because there’s no MagSafe), but only the one that’s furthest back is a fully functional USB 3 port with support for driving an external display at 4K, 60 frames per second. The closer-in USB port only offers USB 2 speeds. (The good news is that Apple has built alerts into macOS that will warn you if the device you’ve plugged into the slow port would be better off plugged into the faster one, so you won’t be transferring files slowly unnecessarily.)

It reminded me of Christina Warren’s angry Mastodon post about the Neo’s ports:

I’m just going to say that pointing out flaws in $600 and $700 laptops and having people instinctively respond “it’s not for real users, these buyers don’t know/care” is gross. Why should we make the assumption that those buyers don’t still deserve better, or at least on par with the 6 year old product it’s replacing that sold at the same price. Stop assuming people who don’t spend $1000+ on tech are imbeciles or deserve subpar options. No one in 2026 deserves a laptop with a single USB 3 port.

My first thought upon reading Christina’s complaint last week was “Why should I care about the configuration of a computer I’ll never buy?” Kind of a Republican thought, I admit, and I’m not proud of it. But I have many reasons to be disappointed by Apple, and I need to conserve my outrage. Christina’s much younger than I am and has deeper outrage reserves.

Jason pointed out the biggest problem with the low-speed port in his next paragraph:

Honestly, I’m more disappointed by the fact that mismatched ports can lead to user frustration—no, not that port, the other one—than I am about the one slow USB port.

Many Neo users will be too young to remember the joy of flipping USB-A plugs back and forth before getting the orientation right. Apple has updated that wonderful experience for the USB-C age.

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.