This is the north side of the bank. The thoroughly incompatible stone addition to the building was (according to Wikipedia) built in the 50s, but I must say the original brick and terra cotta portion of the building is in excellent shape. I don’t know when Chase took over, but they’ve done a great job with the old exterior.

A fun thing about the bank is that it’s wedge-shaped. Here’s an aerial view I pulled from Apple Maps:

The narrow west side of the building used to be the entrance, but it’s now an ATM.

You may be surprised to learn that I don’t find this sacrilegious. It’s a reasonable reuse of a part of the building that wouldn’t make sense as an entrance anymore, and they’ve preserved the glazed terra cotta around it. The signage, though, is awful. Maybe Chase felt the big empty space above the old entrance—which presumably had “Purdue State Bank” removed long ago—didn’t look right without its branding. Wrong.

There are some very nice details around and above the windows. Here’s a closer look at the north side:

And here are essentially the same details on the south side, where the sun didn’t create such harsh shadows:

The shade on the south side also allowed a decent view of the sides of the pillars between the windows.

I have no photos of the interior because it was terribly disappointing. I knew the east half of the building would be generic, but I thought they might have preserved something of the original in the west half. But as I turned right after going through the doors, I saw that wasn’t the case. The entire interior is just white painted drywall and LED lighting. The only thing that sets it apart from any other Chase branch is that the offices in the west half are noticeably squeezed together.

Given the care taken to preserve the exterior, I suspect the interior had been defiled before Chase took over, and there was nothing left in there to care for. That’s a shame, and it was an unfortunate way to end my visits. But the exterior was really nice and certainly worth the trip.

One last thing: Are you surprised to see the Sun hitting the north side of the building? I confess I was. But after thinking about it, it made sense. First, my visit was on July 1, less than two weeks after the summer solstice, which means the Sun rises pretty far north of due east. Second, we’re in Daylight Saving Time, which means the bank’s opening time of 9:00 AM is closer to sunrise than it would be if we were on Standard Time. Finally, West Lafayette is just east of the boundary between the Eastern and Central time zones, and I live just west of the boundary. I’m used to sunrise happening nearly an hour earlier (in local time) than it happens in West Lafayette.

Of course I couldn’t leave it at that. I fired up Mathematica and used its SunPosition function to figure out where the Sun was in the sky when I took that photo (9:22 AM EDT) of the north side of the bank:

As you can see, the Sun’s azimuth, the first item of the result, was about 85°, making it slightly north of east. The same calculation (with the same result) can be made on the web using the NOAA Solar Calculator.

As you can see from the photo above, the Old Home differs from the other jewel box banks in that its exterior is clad entirely in terra cotta—it’s not mostly brick with terra cotta accents. But the accents still manage to stand out.

Let’s not forget the lions, which we’ve seen before. Like the Sidney and Grinnell banks, this one has a protective lion with wings and a shield.

And like the Sidney bank, it has a couple of lion heads with pipes in their mouths to drain rainwater.

The pipes could be a little more subtle.

This is a pretty small building, so when you walk in the door on the east side, you’re put in a fairly narrow space.

Not as narrow as it used to be for visitors to the bank. Near the entrance is this photo from the early days, showing how the teller areas took up the northern half of the space:

The serpentine flooring that runs east-west along the south half of the building is original, which you can see if you compare the vein patterns in my photo and the old one.

The stenciling on the ceiling and walls is mostly original, as evidenced by the discoloration and missing paint in some areas.

The colored window panels on the south wall are original, as are the mechanisms that used to open them. The panels don’t open now because we have air conditioning, and it’s better to keep them sealed.

The benches and check-writing desks along the south wall are original and were found in the building’s basement.

I find the detail on the post highly reminiscent of Frank Lloyd Wright:

Wright worked for Sullivan early in his career but had been gone for over twenty years by the time the Old Home was designed. I don’t know if this was a typical Sullivan detail or whether he was being influenced by his former apprentice.

The basement currently has a handful of old building artifacts: pieces of broken terra cotta, original lighting fixtures, doorknobs, alarm bells, teller cage grills, and safe deposit boxes.

There’s also an odd panel with wiring (at the bottom of the second photo) that looks a lot like a printed circuit board.

Finally, in the Foundation’s office space on the second floor is this gorgeous Sullivan drawing of the building’s south elevation:

Fun fact: the original boiler room was just outside the footprint of the building, under the sidewalk that ran along the east side. Second fun fact: the locker doors shown in the Women’s Room at the west end of the basement are still in the basement but currently decorating a wall.

The building’s drawings are at the Ryerson and Burnham Library at the Art Institute. They’re digitized and available to download, but at a pretty low resolution. Too bad.

• Farmers and Merchants Union Bank in Columbus, Wisconsin
• National Farmers’ Bank in Owatonna, Minnesota
• Henry Adams Building in Algona, Iowa
• Merchant’s National Bank in Grinnell, Iowa
• People’s Savings Bank in Cedar Rapids, Iowa

These all fit in with a little driving circuit that included visiting my daughter and my younger son. This year, I headed east to pick up the last three.

This morning’s bank was the People’s Federal Savings and Loan Association in Sidney, Ohio. Despite what that Wikipedia page says, it’s now operated by F&M Bank, which bought out People’s in 2022. You can sort of tell by the large but tasteful “F&M Bank” lettering on the front (north) façade.

F&M could have used a font in which their F was a better match to the F in the original THRIFT lettering, but you can’t expect bank executives to notice things like that. At least they didn’t go with the sans serif font they use in their logo. The horizontal line of slightly damaged bricks is where the old name of the bank used to be.

The bank was built in 1917, which puts it second to last in the sequence, younger than all the other jewel boxes except the Farmers and Merchants Bank. The date of construction is prominent on the west façade.

You’ll probably need to zoom in to see the date; it’s not only small, but I was shooting into the sun, so the contrast isn’t great. The 1886 date you see at the left end is when People’s Federal Savings and Loan was founded.

While we’re on the west side, let’s check out some of the details.

The lion with the shield on top of a pilaster is at the southwest corner of the building, off the right edge of my west façade photo. You may recognize him—he’s basically the same as the entranceway lions at the Merchant’s National Bank.

Each of the lion heads that appear along the bottom of the windows has a copper pipe in its open mouth. Clearly this is to drain rainwater that collects on the sills, although I don’t know if the pipes are still working. Sullivan undoubtedly considered this a “form follows function” thing.

Most of the decorative elements on this building are organic, but there are geometric features along the cornice at the top of the building and around the arch on the north façade.

Sullivan “signed” this building in the architrave above the entrance. Not just in the little LOUIS SULLIVAN ARCHITECT in the lower left corner, but in the big stylized LSA at the center of the piece.

Just inside the entrance is the landmark designation plaque.

After seeing the lovely exterior, I have to say I was a little disappointed when I went through the foyer into the interior. It’s nice enough, but I was ready to be hit by something like the interior of the National Farmers’ Bank. No such luck. The lines are clean, there’s a good view of the west windows, and there’s a gorgeous skylight running down the center of the ceiling, but no murals or hanging lights.

One of the tellers told me there used to be stencils of some sort running along the tops of the walls, but they were painted over. An odd decision, given how well the rest of the building has been preserved, but maybe they couldn’t be saved—or weren’t original.

Another small disappointment was the lack of documentation. Other banks had small shrines to their buildings, with displays of drawings, old photographs, or even pieces of original terra cotta and brickwork. F&M had a little pamphlet and a visitors’ signature book, but that was it.

I don’t want to be too hard on this bank. It really is beautiful and in great shape. I guess my expectations for the interior were just too high after walking around and photographing the north and west façades. F&M can’t be blamed if the previous owner didn’t keep the original drawings. Also, it’s a pretty small space—no second floor or mezzanine for a shrine.

In a word, the state was sorry. This was largely due to some expedient decisions made in the early 80s that were necessary to get the Mac out the door. Unfortunately, those decisions made the Mac a less and less stable computing environment as the years went on.

The instability had to do with memory and multitasking. Jason and John cover it well in the podcast, so there’s no need for me to get into it. I will say, though, that if you listen to the podcast and think Jason is exaggerating when he says that he would often have to reboot his Mac a dozen or so times per day, I can assure you that’s no exaggeration. The frustration of using a Mac back then was the reason I abandoned it for Linux at the end of 1996.

The problem with the Mac was that it had a great user interface for multitasking but a lousy infrastructure. In the mid-80s, the lousy infrastructure didn’t matter so much because computer users were used to doing one thing at a time, which the Mac handled well. But the windowing OS, the consistency of Mac applications, and the multitasking tease of desk accessories slowly got users hungry to run many apps simultaneously and switch between them at will. The infrastructure couldn’t handle that.

I want to emphasize how important the consistency was. For example, all Mac apps had cut, copy, and paste, and those commands were always in the Edit menu and they always had the ⌘X, ⌘C, and ⌘V keyboard shortcuts.¹ Similarly for Save and ⌘S. DOS programs—and before Windows 95, most PC users were running DOS—didn’t have that consistency. I remember reading back in ’85 or ’86 that Mac users tended to regularly use many more applications than PC users. There were lots of PC users, especially in the workplace, who basically used one program; their computers were configured to boot into WordPerfect or Lotus 1-2-3, and that would be the only program they used until they turned off their machine at the end of the day.

Mac users weren’t like that. Because the Mac had a consistent language, users felt comfortable taking on new apps. They didn’t have to start at ground zero to learn a new set of commands. And when you’re comfortable using three, four, or more programs, you want them all running and available at a moment’s notice. MultiFinder, incorporated into the Finder itself in System 7, offered you the promise of being able to do that, but the underlying deficiencies of the OS reneged on that promise. Classic Mac OS was Lucy and you were Charlie Brown.

and this article in the New York Times about Donald Trump’s declining poll numbers among white working-class voters and how that might affect November’s elections.¹

Forgive me for not being especially optimistic, but one of my distinct memories from 1984 makes me think the polls are lagging.

A news story on one of the networks back in 1984 included short interviews with prospective voters. One of the voters was a young white man (he was about my age at the time) who said he was voting for Ronald Reagan. When asked why, he said “He got me my job back.”

Of course, the man had been laid off early in the Reagan administration,² but that didn’t enter into his reasoning. The only thing that mattered was that he was working again. It was my introduction to the short memories of American voters.

via MoMA

I can’t help but think we’ll see the same thing this November. As long as the price of gas—like the unemployment rate in 1984—keeps going down, it won’t matter whether it gets back to where it had been or who caused it to go up in the first place. White working-class voters (especially men) will credit Trump with bringing gas prices down and vote Republican again, regardless of what they told pollsters recently. Only another major fuckup close to the election will get them to vote blue or just stay home in large numbers.

At the end of yesterday’s post about the combinatorics of the World Cup group stage, I said “this is good enough for me.” Turns out that was a lie. Today I rewrote some of the code to come up with a slightly more detailed result.

The last bit of work in that post was to generate the 40 unique point totals that can come from a group. These are the possible totals, with no regard for which team gets which total:

9 6 3 0     7 6 3 1     7 3 2 2     5 5 3 2
9 6 1 1     7 6 2 1     6 6 6 0     5 5 3 1
9 4 4 0     7 5 4 0     6 6 4 1     5 5 2 2
9 4 3 1     7 5 3 1     6 6 3 3     5 4 4 3
9 4 2 1     7 5 2 1     6 5 4 1     5 4 4 2
9 3 3 3     7 4 4 1     6 5 2 2     5 4 3 2
9 2 2 2     7 4 3 3     6 4 4 3     5 3 3 2
7 7 3 0     7 4 3 2     6 4 4 2     4 4 4 4
7 7 1 1     7 4 3 1     5 5 5 0     4 4 4 3
7 6 4 0     7 4 2 2     5 5 4 1     3 3 3 3

As discussed early in yesterday’s post, there are $3^6=729$ ways the six games of a group can turn out, so today’s script associates each of the above totals with the game results that add up to that total. I built a dictionary in which the keys are the totals shown above—expressed as tuples, like (7, 7, 1, 1)—and the values are lists of lists of game result lists, like

[[[3, 0, 0, 0],
  [3, 0, 0, 0],
  [1, 0, 0, 1],
  [0, 1, 1, 0],
  [0, 0, 0, 3],
  [0, 0, 0, 3]],
 [[3, 0, 0, 0],
  [1, 0, 1, 0],
  [3, 0, 0, 0],
  [0, 0, 3, 0],
  [0, 1, 0, 1],
  [0, 0, 3, 0]],
 [[0, 3, 0, 0],
  [0, 0, 3, 0],
  [1, 0, 0, 1],
  [0, 1, 1, 0],
  [0, 3, 0, 0],
  [0, 0, 3, 0]],
 [[0, 3, 0, 0],
  [1, 0, 1, 0],
  [0, 0, 0, 3],
  [0, 3, 0, 0],
  [0, 1, 0, 1],
  [0, 0, 0, 3]],
 [[1, 1, 0, 0],
  [3, 0, 0, 0],
  [3, 0, 0, 0],
  [0, 3, 0, 0],
  [0, 3, 0, 0],
  [0, 0, 1, 1]],
 [[1, 1, 0, 0],
  [0, 0, 3, 0],
  [0, 0, 0, 3],
  [0, 0, 3, 0],
  [0, 0, 0, 3],
  [0, 0, 1, 1]]]

The innermost lists in this output are the points accumulated in a single game. For example, [1, 1, 0, 0] represents a game in which the first two teams in the group played to a draw. So the above result tells us that there are six ways the six games in a group can lead to a (7, 7, 1, 1) table at the end of the stage.

Here’s the Python code that built the dictionary and printed out a summary of the results:

python:
 1:  #!/usr/bin/env python3
 2:  
 3:  from itertools import product
 4:  from collections import defaultdict
 5:  import numpy as np
 6:  
 7:  # Possible point distributions from each game.
 8:  game1 = [[3, 0, 0, 0], [0, 3, 0, 0], [1, 1, 0, 0]]
 9:  game2 = [[3, 0, 0, 0], [0, 0, 3, 0], [1, 0, 1, 0]]
10:  game3 = [[3, 0, 0, 0], [0, 0, 0, 3], [1, 0, 0, 1]]
11:  game4 = [[0, 3, 0, 0], [0, 0, 3, 0], [0, 1, 1, 0]]
12:  game5 = [[0, 3, 0, 0], [0, 0, 0, 3], [0, 1, 0, 1]]
13:  game6 = [[0, 0, 3, 0], [0, 0, 0, 3], [0, 0, 1, 1]]
14:  
15:  # Enumerate all possible six-game results, and put them in a dictionary.
16:  # The keys are the sorted point totals and the values are the list of
17:  # game results.
18:  games = defaultdict(list)
19:  results = np.array(list(product(game1, game2, game3, game4, game5, game6)))
20:  for r in results:
21:    points = tuple(sorted(r.sum(axis=0).tolist(), reverse=True))
22:    games[points].append(r.tolist())
23:  
24:  # Show how many game results lead to each tuple of sorted point totals.
25:  count = 0
26:  p = sorted(games.keys(), reverse=True)
27:  for k in p:
28:    count += len(games[k])
29:    print(f'({" ".join(str(p) for p in k)}): {len(games[k]):3d}')
30:  print(f'    Total: {count:3d}')

The output is

(9 6 3 0):  24
(9 6 1 1):  12
(9 4 4 0):  12
(9 4 3 1):  24
(9 4 2 1):  24
(9 3 3 3):   8
(9 2 2 2):   4
(7 7 3 0):  12
(7 7 1 1):   6
(7 6 4 0):  24
(7 6 3 1):  24
(7 6 2 1):  24
(7 5 4 0):  24
(7 5 3 1):  24
(7 5 2 1):  24
(7 4 4 1):  36
(7 4 3 3):  24
(7 4 3 2):  24
(7 4 3 1):  24
(7 4 2 2):  24
(7 3 2 2):  12
(6 6 6 0):   8
(6 6 4 1):  24
(6 6 3 3):  24
(6 5 4 1):  24
(6 5 2 2):  12
(6 4 4 3):  36
(6 4 4 2):  24
(5 5 5 0):   4
(5 5 4 1):  24
(5 5 3 2):  12
(5 5 3 1):  12
(5 5 2 2):  12
(5 4 4 3):  24
(5 4 4 2):  24
(5 4 3 2):  24
(5 3 3 2):  12
(4 4 4 4):   6
(4 4 4 3):   8
(3 3 3 3):   1
    Total: 729

where the numbers after the colons are the number of ways the games can go to result in the given totals. There is, for example, only one way to get (3, 3, 3, 3), which is for every game to end in a draw.

The code is not clever in any way. I build the games dictionary (actually a defaultdict) one step at a time via the loop in Lines 20–22. As with yesterday’s script, I generate all the 729 game results using the product function from the itertools library and use NumPy’s sum function to add up the points from each of those results. The output comes from Lines 25–30.

If I run this script in an interactive environment, like IPython or Jupyter, I can pull out the games that lead to any set of points. I think the (5, 4, 3, 2) total is fun because it’s the only straight among the 40 possibilities. After some reformatting, here’s what games[(5, 4, 3, 2)] returns:

(3 0 0 0) (0 0 3 0) (1 0 0 1) (0 1 1 0) (0 1 0 1) (0 0 1 1) 
(3 0 0 0) (1 0 1 0) (0 0 0 3) (0 1 1 0) (0 1 0 1) (0 0 1 1) 
(3 0 0 0) (1 0 1 0) (1 0 0 1) (0 3 0 0) (0 1 0 1) (0 0 1 1) 
(3 0 0 0) (1 0 1 0) (1 0 0 1) (0 1 1 0) (0 3 0 0) (0 0 1 1) 
(0 3 0 0) (3 0 0 0) (1 0 0 1) (0 1 1 0) (0 1 0 1) (0 0 1 1) 
(0 3 0 0) (1 0 1 0) (3 0 0 0) (0 1 1 0) (0 1 0 1) (0 0 1 1) 
(0 3 0 0) (1 0 1 0) (1 0 0 1) (0 0 3 0) (0 1 0 1) (0 0 1 1) 
(0 3 0 0) (1 0 1 0) (1 0 0 1) (0 1 1 0) (0 0 0 3) (0 0 1 1) 
(1 1 0 0) (3 0 0 0) (0 0 0 3) (0 1 1 0) (0 1 0 1) (0 0 1 1) 
(1 1 0 0) (3 0 0 0) (1 0 0 1) (0 0 3 0) (0 1 0 1) (0 0 1 1) 
(1 1 0 0) (3 0 0 0) (1 0 0 1) (0 1 1 0) (0 1 0 1) (0 0 3 0) 
(1 1 0 0) (0 0 3 0) (3 0 0 0) (0 1 1 0) (0 1 0 1) (0 0 1 1) 
(1 1 0 0) (0 0 3 0) (1 0 0 1) (0 3 0 0) (0 1 0 1) (0 0 1 1) 
(1 1 0 0) (0 0 3 0) (1 0 0 1) (0 1 1 0) (0 1 0 1) (0 0 0 3) 
(1 1 0 0) (1 0 1 0) (3 0 0 0) (0 1 1 0) (0 0 0 3) (0 0 1 1) 
(1 1 0 0) (1 0 1 0) (3 0 0 0) (0 1 1 0) (0 1 0 1) (0 0 0 3) 
(1 1 0 0) (1 0 1 0) (0 0 0 3) (0 1 1 0) (0 3 0 0) (0 0 1 1) 
(1 1 0 0) (1 0 1 0) (0 0 0 3) (0 1 1 0) (0 1 0 1) (0 0 3 0) 
(1 1 0 0) (1 0 1 0) (1 0 0 1) (0 3 0 0) (0 0 0 3) (0 0 1 1) 
(1 1 0 0) (1 0 1 0) (1 0 0 1) (0 3 0 0) (0 1 0 1) (0 0 3 0) 
(1 1 0 0) (1 0 1 0) (1 0 0 1) (0 0 3 0) (0 3 0 0) (0 0 1 1) 
(1 1 0 0) (1 0 1 0) (1 0 0 1) (0 0 3 0) (0 1 0 1) (0 0 0 3) 
(1 1 0 0) (1 0 1 0) (1 0 0 1) (0 1 1 0) (0 3 0 0) (0 0 0 3) 
(1 1 0 0) (1 0 1 0) (1 0 0 1) (0 1 1 0) (0 0 0 3) (0 0 3 0) 

Notice that in every set of six games (i.e., each row), there are two games that end in a win and four that end in a draw. The team with five points has a win and two draws; the team with four points has a win, a draw, and a loss; the team with three points has three draws; and the team with two points has two draws and a loss.

OK, now I’m done.

We’re in the middle of the first set of games in the group stage of the 2026 World Cup, and I’ve been thinking about how many ways the points can be distributed among the teams in a given group. I used Python to help with the enumeration.

Here’s a quick summary of how the group stage works: The teams are split into groups of four. Within each group, all the teams play each other once. A team gets three points for a win and one point for a draw in each of the three games it plays. The teams are ranked by their point totals within their group when this stage is over.¹

Six games are played in each group. You can calculate that number in several ways, but it’s easy enough to just list them all. Let’s say the teams in our group are Alpha, Beta, Gamma, and Delta. Then the six games are:

Alpha vs. Beta
Alpha vs. Gamma     Beta vs. Gamma
Alpha vs. Delta     Beta vs. Delta     Gamma vs. Delta

Since there are three possible outcomes in each game (W–L, L–W, and D–D), there are

possible results for the six games of the group stage.

We can get the point distribution among the teams for each of these possible results with this bit of Python code:

python:
 1:  #!/usr/bin/env python3
 2:  
 3:  from itertools import product
 4:  import numpy as np
 5:  
 6:  # Possible point distributions from each game.
 7:  game1 = [[3, 0, 0, 0], [0, 3, 0, 0], [1, 1, 0, 0]]
 8:  game2 = [[3, 0, 0, 0], [0, 0, 3, 0], [1, 0, 1, 0]]
 9:  game3 = [[3, 0, 0, 0], [0, 0, 0, 3], [1, 0, 0, 1]]
10:  game4 = [[0, 3, 0, 0], [0, 0, 3, 0], [0, 1, 1, 0]]
11:  game5 = [[0, 3, 0, 0], [0, 0, 0, 3], [0, 1, 0, 1]]
12:  game6 = [[0, 0, 3, 0], [0, 0, 0, 3], [0, 0, 1, 1]]
13:  
14:  # Enumerate all possible six-game results, add up the points, and sort.
15:  games = np.array(list(product(game1, game2, game3, game4, game5, game6)))
16:  points = games.sum(axis=1)
17:  points = points.tolist()
18:  points.sort(reverse=True)
19:  print(f'Number of point arrangements: {len(points)}')

The output is

Number of point arrangements: 729

which matches our calculation above.

Lines 7–12 give the three possible point allocations for each of the games, where the inner lists are the points given to Alpha, Beta, Gamma, and Delta—in that order. Line 15 uses the product function from the itertools library to build all 729 outcomes. It turns them into a NumPy array because I wanted to use the sum function (Line 16) to add up the points from each game without any laborious looping. After this step, points is a 729×4 NumPy array.

Line 17 then turns points into a list of lists, and Line 18 sorts the 729 entries. It looks like this:

[[9, 6, 3, 0],
 [9, 6, 1, 1],
 [9, 6, 0, 3],
 [9, 4, 4, 0],
 [9, 4, 3, 1],
    .
    .
    .
 [0, 4, 5, 7],
 [0, 4, 4, 9],
 [0, 3, 9, 6],
 [0, 3, 7, 7],
 [0, 3, 6, 9]]

There are repeats among these results. For example, there are two ways to get the result

[5, 5, 4, 1]

This set of points can come from either

Alpha draws Beta       [1, 1, 0, 0]
Alpha beats Gamma      [3, 0, 0, 0]
Alpha draws Delta      [1, 0, 0, 1]
Beta draws Gamma       [0, 1, 1, 0]
Beta beats Delta       [0, 3, 0, 0]
Gamma beats Delta      [0, 0, 3, 0]

or

Alpha draws Beta       [1, 1, 0, 0]
Alpha draws Gamma      [1, 0, 1, 0]
Alpha beats Delta      [3, 0, 0, 0]
Beta beats Gamma       [0, 3, 0, 0]
Beta draws Delta       [0, 1, 0, 1]
Gamma beats Delta      [0, 0, 3, 0]

Sum down the columns to prove to yourself that this yields point totals of

[5, 5, 4, 1]

OK, so how many unique point total results can there be? To answer this, I added the following code:

python:
21:  # Unique points, team-by-team.
22:  unique_team_points = [ list(q) for q in set(tuple(p) for p in points) ]
23:  unique_team_points.sort(reverse=True)
24:  print(f'Number of unique point arrangements: {len(unique_team_points)}')

which output

Number of unique point arrangements: 556

Unlike the 729 results we got earlier, I have no formula for calculating this number, and I have no interest in trying to come up with one. This is one of those situations where brute force programming is the best use of my time.

Line 22 uses the common Python trick of turning a list into a set to eliminate duplicates and then turns the set back into a list. The less-common trick is that it first turns the inner lists into tuples. This is needed because something like

set(points)

returns this error:

TypeError: cannot use 'list' as a set element (unhashable type: 'list')

In these 556 results, we kept the teams separated. In other words, we considered results

[9, 6, 3, 0]
[9, 6, 0, 3]
[9, 3, 6, 0]
[9, 3, 0, 6]
[9, 0, 6, 3]
[9, 0, 3, 6]
    etc.

to be different because the team scores were different. But what if we just wanted to know the possible point combinations without regard to which team got which point total? Again, I have no formula for this, but it was easy to work it out in code:

python:
26:  # Unique points without regard to team.
27:  sorted_points = sorted((sorted(p, reverse=True) for p in points), reverse=True)
28:  unique_points = [ list(q) for q in set(tuple(p) for p in sorted_points) ]
29:  unique_points.sort(reverse=True)
30:  print(f'Number of unique sets of points: {len(unique_points)}')
31:  print()
32:  point_strings = [ f'{p[0]} {p[1]} {p[2]} {p[3]}' for p in unique_points ]
33:  print('\n'.join(point_strings))

The first line of output is

Number of unique sets of points: 40

which is quite a reduction. The number is now small enough to show all of them. Reshaping the 40 output lines that follow into four columns of ten gives

9 6 3 0     7 6 3 1     7 3 2 2     5 5 3 2
9 6 1 1     7 6 2 1     6 6 6 0     5 5 3 1
9 4 4 0     7 5 4 0     6 6 4 1     5 5 2 2
9 4 3 1     7 5 3 1     6 6 3 3     5 4 4 3
9 4 2 1     7 5 2 1     6 5 4 1     5 4 4 2
9 3 3 3     7 4 4 1     6 5 2 2     5 4 3 2
9 2 2 2     7 4 3 3     6 4 4 3     5 3 3 2
7 7 3 0     7 4 3 2     6 4 4 2     4 4 4 4
7 7 1 1     7 4 3 1     5 5 5 0     4 4 4 3
7 6 4 0     7 4 2 2     5 5 4 1     3 3 3 3

These are the point totals for the 40 different ways a group stage can end. The two levels of sorting in Line 27 are the key to bringing the results down from 729.

You can go to ESPN’s World Cup table for 2022 to show which of these 40 results occurred that year. There’s a popup menu button on the page that lets you check 2018, 2014, 2010, and 2006, too.

I’m sure serious soccer fans have been digging into the math behind this year’s change from eight groups to twelve. I’m not a serious fan, so this is good enough for me.

The trail has mile markers with little snippets of information about the canal and the surrounding area. Here are the markers I passed this morning:

The mileage figures on the markers increase as you go south and west, which is downstream. There are several more markers in Lockport, where they’re graduated in tenths of a mile, but these will do for our purposes.

My ride started nearly a mile before Marker 27 and continued about a mile after Marker 31, which would lead you to believe I rode six miles, not eight. But the trip is definitely eight miles. I have my Fitness app set to record in kilometers, and it always tells me this trip is 13 kilometers one way. And as we know from the Fibonacci conversion, 13 km = 8 mi.

As I passed Marker 27 on the way south, I was reminded of this anomaly and decided to use the trip to figure out why the markers and the mileage don’t match up. I checked my Workout screen on my watch as I passed each marker and learned that there were two miles between Markers 28 and 29 and between Markers 30 and 31. After turning around in the parking lot of the Joliet Iron Works, I decided to take a photo of each marker on the way back north and use the photos to calculate distances.

I already knew about Mathematica’s GeoDistance function, and I figured it must have a way of extracting the latitude and longitude of photos from their EXIF data. That turned out to be the Import function, and I was able to put the two together to make this short notebook:

As you can see, the distances between the photos (and therefore between the markers) were:

These are geodesic or “as the crow flies” distances. The canal and its trail are pretty straight, but there are a couple of doglegs between Markers 28 and 29, which explains why the distance between them is over a tenth of a mile off from two miles.

As you can see near the bottom of the notebook, I used the GeoListPlot function to make a map with the marker positions on it. I combined that in Acorn with the map from my iPhone’s Fitness app to make this image:

It took some trial and error with the GeoRange option to get the scales to match up reasonably well, but I think it was worth it. You can see where the mile markers fall on my route, and it’s clear that the distances between Markers 28 and 29 and Markers 30 and 31 are about twice as far as the other distances. Also, you can see how the geodesic distance between Markers 28 and 29 cuts the corners, making it less than two miles.

So I’ve solved the six-mile/eight-mile mystery, but I still don’t understand why the mileage on the markers is wrong.

After my last post—the one about using Fourier series—I started thinking about how to use Mathematica to develop Fourier series.¹ I could, of course, use the Integrate function to determine the Fourier coefficients, but Mathematica has other functions that can do the job directly once you understand how they work.

Mathematica has several Fourier functions, but I’m going to stick with the ones associated with sine series, FourierSinCoefficient and FourierSinSeries. They’re meant to be easy to use, and they are, but you need to know how they’re defined.

The coefficients used in both of these functions are defined this way:

This doesn’t match up exactly with the definition I used for getting the Fourier coefficients of a loading function, $q(x)$:

To use the Mathematica functions to get the $q_n$, we have to do a change of variable. Let

so

(Here, z is just another variable name; I’m not using it to represent a complex number.)

This changes the expression for $q_n$ to

which means we can use the Mathematica functions as long as we substitute $Lz/\pi$ in for $x$ in the expression for $q$.

Let’s give it a try on this parabolic loading function:

It shouldn’t take many Fourier terms to get a good approximation of this.

Here are the Mathematica commands I used:

q = 4 qmax x (L - x)
qn = FourierSinCoefficient[q /. x -> L z/Pi, z, n]

You can see the substitution in the first argument to FourierSinCoefficient.

After simplification, the results were

We could also get the series (through $n=7$) directly with FourierSinSeries:

qapprox2 = FourierSinSeries[q /. x -> L z/Pi, z, 7] /. z -> Pi x /L

where the inverse substitution comes at the end to put the expression back in the form we want. Here’s a screenshot from the Mathematica notebook:

You can see that the coefficients match what we got earlier.

A quick plot of the difference between this truncated Fourier series and the original parabolic function shows that, as expected, the series does a good job of replicating the original. The largest error, near the ends, is just 0.3% of $q_{max}$, and that’s with only four terms.

If you’re interested, here’s the entire Mathematica notebook:

Now that I understand the way these functions work, I can do more complicated Fourier analysis in Mathematica without questioning myself on whether I’m using them correctly.

We’re finally here, at the end of all things. In this post, we’ll use a Fourier series to get the formula for the center deflection of a simply supported beam with a uniformly distributed load. We’ll see some of the same math that we saw in the previous Fourier series solution, but the fundamental approach will be different.

Let’s start with the fourth-order ordinary differential equation for a beam with a general loading function, $q(x)$:

The simple supports at both ends give us these boundary conditions:

Let’s work out the solution for a loading condition we haven’t considered before, a distributed load in the form of a sine wave:

where $m$ is a positive integer and $q_m$ is some constant amplitude. Given the form of the governing ODE and the boundary conditions, it seems likely that the solution will look like this:

It satisfies the boundary conditions, and if we plug it and the expression for q into the governing ODE, we get

which is a solution for all values of x if

This will work for any value of m that’s a positive integer.

Since the governing ODE is linear, if q is the sum of several sine terms, the solution will be the sum of several sine terms. Returning to our favorite problem,

we now have a path for expressing the solution as a sum of sines, as long as we can express the constant function, $q(x)=w$, as a sum of sines.

And of course we can. The Fourier sine series expression that fits a constant is

where

This result comes from the orthogonality of the sine function. The Fourier coefficients are the same as those for a square wave.

Plugging this result into the expression for $y_m$, we get

for odd m. Therefore,

You may recall from our earlier post that there’s a closed-form solution for this sum:

The last entry in this table with $x=\pi /2$ gives us

Substituting the closed-form solution in for the sum yields our old friend:

The purpose of this series of posts—apart from a bit of showing off—was to demonstrate why I love structural analysis. It has, even in the simplest of problems, a depth that rewards those who study it. And when you’re confronted with problems that aren’t so simple, you can draw on that depth to understand and solve them.

This would have been the last post in the series if I hadn’t realized recently that another method deserved a post. So this is the penultimate. It was described in this 1943 paper by Nathan Newmark and is known—or was known—as Newmark’s method.

I say was because this method is dead. How dead? Forty-five years ago, when I was an undergraduate taking structural analysis courses, Newmark’s method wasn’t being taught in the department that he had been the head of for decades and whose main building is named after him. That’s dead.

Which isn’t to say it wasn’t a good method. Some of my professors talked about using it when they were young, and it was a practical technique when engineers used slide rules and desk calculators, but it was clear by the 80s that its time had passed. Still, it’s desncribed in the textbook I used as an undergrad, and I did eventually learn it well after I was out of school, so here it is.

Newmark’s method is basically a way of doing double integration, so you can use it to go from loading to bending moments or from bending moments to deflection. As Newmark says in the introduction to his paper,

The numerical procedure is approximate, but leads to exact moments (or deflections) when the loading diagram (or diagram of “angle changes”) is made up of segments that are bounded by straight lines or by arcs of parabolas.

For our simply supported, uniformly loaded beam, the “angle change” diagram—which we’ve been calling a curvature diagram—is a parabola, so we can get an exact solution.

Let’s say we have a beam with any kind of support conditions and some general distributed loading:

The fundamental trick of Newmark’s method is to imagine a set of simply supported beams inserted between the load and the real beam.

The small imaginary beam segments are all of the same length, $\lambda$, and the analysis proceeds by calculating the reaction forces at the ends of these beams and then building a table of loads, shears, and moments based on these reactions (reversed in direction) acting on the large original beam.

Here’s a figure from the paper that explains how to calculate the reaction forces for parabolically distributed loading:

There are simpler formulas if the loading is distributed linearly.

You may have noticed the double curvature in the right drawing, which means that the load shown there is not parabolic. Newmark suggests using the formulas in this figure even if the loading curve is of higher order—the parabolic formulas are close enough if you divide the beam into several segments.

I’ve focused here on the process of going from loads to bending moments because I think the mechanics of that is easier to understand. But the same process applies to going from curvature to deflection. We went through that in the conjugate beam post.

In fact, Newmark does our problem in the paper. He uses the constant q as the intensity of the load and splits the beam into four segments:

This may look impenetrable, but we can simplify it by using only two segments and explaining each step. Here’s the table, starting with the moment diagram:

The row labeled Moment is the value of the bending moment at each point. The Curvature row is just the moment at each point divided by EI and with the sign reversed. Those are the easy ones.

The Angle change row is based on the curvature values and the formulas in Figure 5 above. The value at the left end is

where we’ve used $\lambda =L/2$. This is also the value at the right end.

The value at the center is

We start the Average slope row with the knowledge that the slope at the center of the beam is zero, so if the angle change across the center is

then the average slope must go from

as we move from the left half of the beam to the right half.

(If you’re having trouble with this, remember that angle change is analogous to shear and think of a beam with an antisymmetric shear diagram. If the change in shear across the centerline is $-F$, then the shear must be $F/2$ in the left half of the beam and $-F/2$ in the right half.)

For the Deflection row, we know that the deflection is zero at the left and right ends. Since the average slope in the left half of the beam is

the deflection at the center must be

an answer we’ve now seen twelve times.

We’re in the home stretch of this series, so ANIAT will soon go back to complaining about Apple’s UI choices.¹ Next week’s WWDC keynote should provide some inspiration.

But today’s post covers our eleventh method for deriving the center deflection of a uniformly loaded simply supported beam: the dummy unit load method. When I was an undergraduate, this was the method we used to determine the deflections of truss structures, but it’s more general than that. My favorite explanation of why it works is in Nicholas J. Hoff’s The Analysis of Structures. I have the original Wiley hardcover of this book, but you can apparently get both paperback and hardcover reprints.

Hoff uses the principle of virtual work in his explanation, and I’d like to quote him here, but unfortunately his explanation is split between one section on the analysis of trusses and another on the analysis of beams. I couldn’t figure out a nice way to put them together coherently, so you’re just going to have to trust me.

For a beam, you can get the deflection at a particular point by following these steps:

1. Work out an equation for the bending moment, M, in the beam for the given set of applied loads.
2. Imagine that same beam with those loads removed (this is the dummy structure) and a concentrated unit load placed at the point at which we want the deflection. By definition, the magnitude of a unit load is one. The unit load points in the direction of the deflection we want to calculate.
3. Work out an equation for the bending moment, m, in the dummy beam with the unit load.

4. The desired deflection is

   $$\delta ={\int }_0^L\frac{mM}{EI}dx$$

Let’s apply this simple principle to our problem:

The bending moment is

where the x coordinate starts at the left end of the beam and increases to the right, as usual.

This same structure with just a unit load at the center is

Its bending moment is

and m is symmetric about the center of the beam.

Therefore,

and we can take advantage of symmetry to say

You can pretty much do this problem in your head if you’re good at figuring out least common multiples. I’m not, but after writing things out, I did realize that the LCM of $24$ and $64$ is $192$.