My OmniGraffle ticks

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

Radii relationship

Don’t be offended—I trust you all to know why the horizontal components of the two diagonals are r0/2 and r1/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:

Simply-supported beam sketch

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:

Simply-supported beam OmniGraffle drawing

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.1 I’ve usually used a different style of arrowhead for the dimensions than for the forces. OmniGraffle has a huge number of arrowhead styles:

OmniGraffle arrows

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.

Structural stencils for OmniGraffle

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.


  1. As you can see, I have not been consistent in my use of blue or black for the dimensions themselves. 


Easy to be hard

Here’s a geometry puzzle from the March issue of Scientific American. If you see the trick, it’s easy to solve.1 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:

SciAm circle puzzle by Amanda Montañez

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 r0, and the next largest circle, the radius of which we’ll call r1:

Radii relationship

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

r0=r1+r12+r02

Multiplying through by 2 and rearranging, we get

r1=212+1r0

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:

r1=212+12+12+1r0=212+22+1r0=13+22r0

This relationship also holds for any two consecutive circles,

ri=13+22ri1

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

ri=1(3+22)ir0

So the sum of all the circumferences is 2π times the sum of all the radii:

2π[r0+2i=11(3+22)ir0]=2πr0[1+2i=11(3+22)i]

Note that there’s only one circle with radius r0, 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

i=112i

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

r0=122

so the sum of the circumferences is

π2[1+2i=11(3+22)i]

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 π.

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

12[1+2i=1n1(3+22)i]

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

n Sum
1 0.94974747
2 0.99137803
3 0.99852070
4 0.99974619
5 0.99995645
6 0.99999253
7 0.99999872
8 0.99999978
9 0.99999996
10 0.99999999

or as a plot,

Convergence 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 π. You can, I guess, consider this numerical exercise as a check on Mathematica’s work. Or a check on the easy solution.


  1. SciAm also uses the trick in its solution, which you won’t see if you click on the link in this paragraph. It’s one link further away. 


Chinese New Year and Ramadan

Yesterday was Chinese New Year and today is the first day of Ramadan. Both of these dates are based on yesterday’s new moon, so I thought it would be fun to write a little script to see how often the dates coincide.

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.


Another Apple icon regression

Apple’s *OS 26 icons have been getting some well-deserved criticism over the past couple of months. There was Jim Nielsen’s complaint about menu icons in macOS. Then came Nikita Prokopov’s more detailed criticism of those same icons.1 And a lot of fun has been poked at Tahoe’s app icons, reaching a peak in heliograph’s deadpan post on Threads.

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,

CarPlay icon screen example

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

CarPlay split screen example

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:2

Old CarPlay split screen icon

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,3 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.


  1. Brent Simmons figured out how to get rid of these abominations, a service to humanity deserving of a Nobel Prize. 

  2. I couldn’t find an image of this button in my Photos library, so I stole it from this TidBITS Talk page

  3. Of course, Apple wouldn’t use an asshole icon—that’s Anthropic’s branding.