I don’t make a habit of reading obituaries, but I’m glad I clicked the link to this one in yesterday’s New York Times (that should be a gift link). Steve Selvin was a statistician who got his Ph.D. at the University of California, Berkeley, and taught there for many years. He got into the Times because of a probability puzzle he came up with in 1975: the Monty Hall Problem.

I won’t explain the problem here. Most of you already know it, and those who don’t can read the setup in the Wikipedia article. I do want to praise the Times for the cute little interactive game they included in Selvin’s obituary. It allows you to be a Let’s Make a Deal contestant and run through the problem again and again (with your computer playing the Monty Hall role) until you’re convinced that the “switching my choice” strategy is distinctly better than the “sticking with my original choice” strategy. I doubt you have the patience to play it enough times to confirm that switching wins 2/3 of the time and sticking wins 1/3 of the time.

I was less pleased with the explanation the Times gave for the probabilities:

After the first reveal, you have two doors, so you should have a 50-50 chance. Right? But you don’t. The host hasn’t randomly eliminated a door; he has deliberately revealed a goat, using his knowledge of where the car is. Your original door still has a one-in-three chance of hiding the car, while switching gives you a two-in-three chance of winning.

It’s right, of course, but it doesn’t strike me as an actual explanation—it sounds more like a restatement of the answer. To me, the way to think of it is to consider the winning strategy:

If you chose the door with a car behind it on your first guess—which will happen 1/3 of the time—you will win by sticking with that door. If you chose one of the doors with a goat behind it on your first guess—which will happen 2/3 of the time—you will win by switching to the door that Monty didn’t open. Therefore, switching gives you a 2/3 chance of winning.

Everyone’s different, so maybe you don’t need those extra words and the Times explanation is sufficient. Not for me, though.

I mentioned above that although you could play the game in the obituary enough times to get a decent estimate of the probabilities, most of us don’t have that kind of patience. The better way to run lots of simulations in a short time is to use a random number generator to have the computer do all the selecting. I’ve been meaning to try out the Julia programming language for quite a while; this seemed like a good problem to start with.

Here’s my script, switch.jl, for running 10,000 simulations using the “switch” strategy:

 1:  #!/usr/bin/env julia
 2:  
 3:  # Parameters
 4:  N = 10_000    # Number of trials
 5:  m = 0         # Number of wins
 6:  
 7:  # Loop through N trials, counting the number of wins
 8:  for i in 1:N
 9:    # Behind-the-scenes preparation
10:    carDoor = rand(1:3)
11:    goatDoors = [j for j in 1:3 if j != carDoor]
12:    
13:    # Player makes initial choice
14:    playerDoor = rand(1:3)
15:    
16:    # Monty chooses an available goat door
17:    if playerDoor == carDoor
18:      # Pick either of the two available
19:      montyDoor = goatDoors[rand(1:2)]
20:    else
21:      # Pick the one available
22:      montyDoor = [j for j in goatDoors if j != playerDoor][1]
23:    end
24:    
25:    # Player switches to the other door
26:    playerDoor = [j for j in 1:3 if (j != montyDoor) && (j != playerDoor)][1]
27:    
28:    # Increment m if the player wins
29:    if playerDoor == carDoor
30:      global m += 1
31:    end
32:  end
33:  
34:  # Print the winning fraction for this strategy
35:  println(m/N)

Because I’m new to Julia, I put in lots of comments, so I doubt there’s much need for more explanation. I will say, though, that I suspect a real Julia programmer wouldn’t use list comprehensions as often as I did. There’s probably a function for removing items from a list that’s more elegant than what I did in Lines 11, 22, and 26. I just don’t know what that is yet.

My script for running 10,000 simulations of the “stick” strategy, cleverly named stick.jl, is basically the same:

 1:  #!/usr/bin/env julia
 2:  
 3:  # Parameters
 4:  N = 10_000    # Number of trials
 5:  m = 0         # Number of wins
 6:  
 7:  # Loop through the N trials, counting the number of wins
 8:  for i in 1:N
 9:    # Behind-the-scenes preparation
10:    carDoor = rand(1:3)
11:    goatDoors = [j for j in 1:3 if j != carDoor]
12:    
13:    # Player makes initial choice
14:    playerDoor = rand(1:3)
15:    
16:    # Monty chooses an available goat door
17:    if playerDoor == carDoor
18:      # Pick either of the two available
19:      montyDoor = goatDoors[rand(1:2)]
20:    else
21:      # Pick the one available
22:      montyDoor = [j for j in goatDoors if j != playerDoor][1]
23:    end
24:    
25:    # Player sticks with original choice; do nothing
26:    playerDoor = playerDoor
27:    
28:    # Increment m if the player wins
29:    if playerDoor == carDoor
30:      global m += 1
31:    end
32:  end
33:  
34:  # Print the winning fraction for this strategy
35:  println(m/N)

The only difference is in Lines 25–26, where I’m basically doing a no-op.

These scripts give different answers each time they’re run because the random number generator starts with a different seed, but the answers are always close to 0.67 for switch.jl and 0.33 for stick.jl. As expected.

Are 10,000 simulations enough? Well, the 95% confidence interval can be calculated through this formula:

$$\pm 1.96\sqrt{\frac{p(1-p)}{N}}$$

which works out to ±0.009 for both strategies. So 10,000 simulations is fine as long as we’re willing to accept the second decimal place to be off by one every now and then.

SnapClip is a Keyboard Maestro macro that puts a graphical user interface on a Python script, process-screenshot. The problem that led to the error was a particular branch of process-screenshot: the branch that puts the screenshot onto the clipboard. I’m not going to rehash the design of SnapClip or process-screenshot here—you can read the old post about them if you want the details.

The branch of process-screenshot that failed runs the impbcopy command-line utility written by Alec Jacobson over a decade ago. I’ve had impbcopy running successfully on my Macs for many years, but last week it failed with the error message

Bad CPU type in executable

I assumed the problem was that impbcopy had been compiled back when I was using an Intel Mac, and it had continued to work because of Rosetta. I thought that because I had Rosetta installed before, it would be updated along with macOS 27, but it wasn’t. Running

softwareupdate --install-rosetta

as described on the Rosetta page got SnapClip working again.

But macOS 27 is the end of the road for Rosetta, so it seemed like a change was due. I installed the Xcode Command Line Tools and tried to recompile impbcopy for Apple Silicon, but that failed with error messages that I couldn’t interpret because I’m not an Objective-C programmer. So I had four options:

1. Learn enough about gcc/Objective-C/clang to get the compilation to work. Even if I could do this, I assumed it would be a lot of work with no future value for me.
2. See if I could rewrite the SnapClip macro to use Keyboard Maestro features to put the image on the clipboard. This was more appealing, but I really liked the way the macro was structured and preferred to leave it as a GUI wrapper.
3. Look into using Shortcuts to put the image on the clipboard and—if it can—replace the call to impbcopy with an equivalent call to the shortcuts utility. But I hate Shortcuts and would rather avoid it if possible.
4. Work out an AppleScript solution and put a call to osascript into process-screenshot. I knew that AppleScript has commands for reading files and putting things on the clipboard, so I went with this, even though AppleScript may be more of a dead end than Objective-C.

Apple’s online documentation for AppleScript sucks, but I have three old AppleScript books that collectively weigh over nine pounds:

• AppleScript: The Definitive Guide by Matt Neuburg.
• AppleScript 1-2-3 by Sal Soghoian and Bill Cheeseman.
• Learn AppleScript by Hamish Sanderson and Hanaan Rosenthal.

The answer (more or less) was in Learn AppleScript and led to just a couple of changes to process-screenshot. Here’s the new version:

python:
 1:  #!/usr/bin/env python3
 2:  
 3:  import tempfile
 4:  from PIL import Image
 5:  import os
 6:  import subprocess
 7:  import shutil
 8:  from datetime import datetime
 9:  import urllib.parse
10:  import argparse
11:  
12:  # Handle the arguments
13:  desc = 'Process a screenshot saved to a file.'
14:  ep = '''If a title is given, it saves the image to a file on the
15:  Desktop with a filename of the form yyyymmdd-title.png.
16:  If no title is given, the image is put on the clipboard and the
17:  upload option is ignored.'''
18:  parser = argparse.ArgumentParser(description=desc, epilog=ep,
19:            formatter_class=argparse.RawDescriptionHelpFormatter)
20:  parser.add_argument('-b', '--background', help='add desktop background border', action='store_true')
21:  parser.add_argument('-u', '--upload', help='upload to images directory and print URL', action='store_true')
22:  parser.add_argument('-t', '--title', help='image title', type=str)
23:  parser.add_argument('ssfile', help='path to screenshot file')
24:  args = parser.parse_args()
25:  
26:  # Parameters
27:  type = "png"
28:  bgcolor = (85, 111, 137)
29:  border = 32
30:  optimizer = '/Applications/ImageOptim.app/Contents/MacOS/ImageOptim'
31:  ascript = f'set the clipboard to (read POSIX file "{args.ssfile}" as picture)'
32:  
33:  # Add a desktop background border if asked for
34:  if args.background:
35:    snap = Image.open(args.ssfile)
36:    # Make a solid-colored background bigger than the screenshot.
37:    snapsize = tuple([ x + 2*border for x in snap.size ])
38:    bg = Image.new('RGBA', snapsize, bgcolor)
39:    bg.alpha_composite(snap, dest=(border, border))
40:    bg.save(args.ssfile)
41:  
42:  # Optimize the file
43:  subprocess.run([optimizer, args.ssfile], stderr=subprocess.DEVNULL)
44:  
45:  # Save it to a Desktop file if a title was given; otherwise,
46:  # save it to the clipboard
47:  if args.title:
48:    sdate = datetime.now().strftime("%Y%m%d")
49:    desktop = os.environ['HOME'] + "/Desktop/"
50:    fname = f'{desktop}{sdate}-{args.title}.{type}'
51:    shutil.copyfile(args.ssfile, fname)
52:    bname = os.path.basename(fname)
53:  
54:    # Upload the file and print the URL if asked
55:    if args.upload:
56:      year = datetime.now().strftime("%Y")
57:      server = f'user@server.com:path/to/images{year}/'
58:      port = '123456789'
59:      subprocess.run(['scp', '-P', port, fname, server])
60:      bname = urllib.parse.quote(bname)
61:      print(f'https://leancrew.com/all-this/images{year}/{bname}')
62:  else:
63:    subprocess.run(['osascript', '-e', ascript])
64:  
65:  # Delete the temporary file
66:  os.remove(args.ssfile)

The changes are:

• Line 31, which is an added line that defines the AppleScript command that does what impbcopy used to do; and
• Line 63, which runs the ascript command via osascript.

The AppleScript that does the work is just one line:

set the clipboard to (read POSIX file "<name of file>" as picture)

Very simple, and I suspect it will work for quite a while. I feel certain that Apple would like to kill AppleScript, but I don’t think it can—too many valuable customers (a group that doesn’t include me) would get very angry at having their longstanding automations die.

One thing that kind of surprised me was the as picture part of the command. Learn AppleScript says that you typically have to include an image type in the command: as GIF picture or as JPEG picture or as TIFF picture. The book suggests that a bare as picture is supposed to work only on PICT images. Never heard of a PICT image? That’s probably because it was the native Mac image format back in the classic days. It was one of Bill Atkinson’s contributions to the Macintosh Toolbox. Nobody saves image files as PICTs anymore.

And yet the unadorned as picture works. I created this test image in Acorn,

and saved it in several formats: BMP, GIF, HEIC, JPEG, JPEG 2000, PNG, and TIFF. I put the files in a folder named clipboard-test on my Desktop,

and ran this AppleScript for each of the different file extensions:

applescript:
set filePath to path to desktop folder as text
set imageFile to (filePath & "clipboard-test:Test image.bmp") as alias
set the clipboard to (read file imageFile as picture)

Each time I ran the script, the clipboard was loaded with the image, no matter which file was being read. I didn’t have to specify the format.

I suspect that if I were using AppleScript to write image data to a file, it wouldn’t be as forgiving. But process-screenshot uses Python and Pillow to save image files, so I don’t need to worry about AppleScript’s idiosyncrasies for that aspect of the script.

If you’ve done Fourier series approximations of functions, you had three reactions to today’s XKCD comic:

First, of course, was a smile of recognition. Then came a “wait a minute” as you realized that the Gibbs phenomenon doesn’t get smaller as you add more terms to the Fourier expansion; it just concentrates itself at the corners:

That ringing never goes away. Here, for example, is the plot for

$$\sum _{k=1,3,5,\dots }^{99}\frac{4}{k\pi }\sin (k\pi x)$$

Finally, you realized that thinking like this ruins the joke.

Yesterday, Numberphile released a delightful video with James Grime (redundant, I know) in which he walks us through a geometry problem first posed by Henry Dudeney in 1902. It’s known as the “Haberdasher’s Puzzle” and is reproduced in Dudeney’s 1907 book The Canterbury Puzzles. The problem was solved by C.W. McElroy after Dudeney published it in a periodical called the Weekly Dispatch.

The problem is to cut up an equilateral triangle into pieces that can be translated and rotated (not flipped) to fit together into a square. The minimum number of pieces that allow you to do this is four, and here’s the arrangement shown in the video:

What James doesn’t do in the video is explain how you position the cuts. Dudeney shows a straightedge-and-compass construction in his book, but I wanted an algebraic solution. This turned out to be more complicated than I anticipated, but I had Mathematica to keep track of the messy algebra.

Let’s start with the equilateral triangle and its component pieces. The points that define the vertices of the triangle and cut lines are given the labels A through J (to avoid confusion, I is omitted).

The lines GJ and DH are perpendicular to Line EF.

To make the explanation simpler, let’s jump to the end and show how to make a square out of these components. The fun way to do it is in a series of rotations:

1. Rotate the green piece 180° about Point G.
2. Rotate the green and orange pieces together 180° about Point E.
3. Rotate the green, orange, and blue pieces together 180° about Point D.

Here’s an illustration of the steps:

In this illustration, the red piece stays put through all the steps.

We can rotate the square to make its sides horizontal and vertical and label the various points to show where they ended up.

The vertices of the equilateral triangle have coalesced into a single point in the interior of the square. The right angles at H and J have split up to form the corners of the square.

Before we get into the algebra of the situation, let’s think about the various dimensions. The side lengths of the square, s, must be equal, so

$$s=2\stackrel{——}{GJ}=2\stackrel{——}{DH}=\stackrel{——}{EJ}+\stackrel{——}{EH}=\stackrel{——}{FH}+\stackrel{——}{FJ}$$

A bit of algebra tells us that

$$\begin{array}{cc}\hfill 2s& =\stackrel{——}{EJ}+\stackrel{——}{EH}+\stackrel{——}{FH}+\stackrel{——}{FJ}\hfill \\ \hfill & =(\stackrel{——}{EJ}+\stackrel{——}{FJ})+(\stackrel{——}{FH}+\stackrel{——}{EH})\hfill \end{array}$$

Looking back at the drawing of the equilateral triangle, we see that the terms in the parentheses make up Line EF. Therefore, the length of EF is the side length of the square, s.

Now it’s time for some analytic geometry. We’ll put the origin of our xy coordinate system at Point A, and we’ll assume each side of the equilateral triangle has unit length. The coordinates are:

$$\begin{array}{cc}\hfill A:& (0,0)\hfill \\ \hfill B:& (1,0)\hfill \\ \hfill C:& (\frac{1}{2},\frac{\sqrt{3}}{2})\hfill \end{array}$$

The area of the triangle is

$$\frac{1}{2}(1)\left(\frac{\sqrt{3}}{2}\right)=\frac{\sqrt{3}}{4}$$

This is the same as the area of the square, so

$$s=\frac{3^{1/4}}{2}$$

This will be the length of $\stackrel{——}{EF}$.

Points D and E are the midpoints of AC and BC:

$$\begin{array}{cc}\hfill D:& (\frac{1}{4},\frac{\sqrt{3}}{4})\hfill \\ \hfill E:& (\frac{3}{4},\frac{\sqrt{3}}{4})\hfill \end{array}$$

Since we know the length of Line EF and the position of Point E, we can calculate the position of Point F along Line AB:

$$F:(\frac{1}{4}[3-\sqrt{4\sqrt{3}-3}],0)$$

As I said, it’s kind of messy, but that’s what Mathematica is for. To six decimal places, the x coordinate is 0.254508. This is almost directly under Point D, but not quite.

Now we need the position of Point G. As it happens, it’s exactly $\frac{1}{2}$ unit to the right of Point F:

$$G:(\frac{1}{4}[5-\sqrt{4\sqrt{3}-3}],0)$$

To six decimal places, this is 0.754508.

How do we know this? Consider this drawing:

The light green triangle, DEH, is congruent to the dark green triangle, GFJ. We know this because:

1. The right angle at H matches the right angle at J.
2. The length of DH is equal to the length of GJ (see the discussion above).
3. The angle at D matches the angle at G because DE is parallel to FG and DH is parallel to GJ.

We therefore have an angle-side-angle congruence. The light green triangle is a duplicate of the dark green triangle, rotated 180° and moved up so its horizontal side is aligned with DE. The distance between D and E is $\frac{1}{2}$, so that must also be the distance between F and G.

With the locations of F and G known, we can find H and J by running lines perpendicular to EF that intersect F and G. The full equations for the positions of H and J are even messier than those of F and G, so I’ll just give the six-place decimal approximations:

$$\begin{array}{cc}\hfill H:& (0.466506,0.185267)\hfill \\ \hfill J:& (0.538001,0.247746)\hfill \end{array}$$

If you want to go through the Mathematica that generated these results and the graphics, here it is:

Why is this? Well, one reason could be that I don’t already have a HomePod in my kitchen, which makes me behind the times. I’ve been thinking I should get one (or two), but Siri’s deficiencies have kept me back. Also, I like the idea of a status board but didn’t want to dedicate an iPad to that. The recently improved Siri and the HomeView’s touchscreen kill those two birds with one $300 stone.

And I think I have a good place for it in my kitchen. Not on the center island. The two likely spots for it on the island are corners that are already taken:

• The corner that currently has a shallow wooden bowl that my dad turned and that I finished after his death. It’s where I put fruit and vegetables that don’t need refrigeration and is currently holding an avocado that should be ripe tomorrow.
• The corner that has a vase I keep filled with flowers from Trader Joe’s. That’s where Janet put flowers, and it isn’t going to change.

Another obvious place would be the kitchen desk. Many years ago, we had a laptop computer on the desk, so it has a history of similar use. But the desk isn’t in a great spot for the HomeView—a little too far away from the island to look at it while I’m preparing a meal, and maybe a little too far away from the kitchen table to use as a status board.

But there is a perfect spot at the end of one of the counters. It’s near both the kitchen table and the island. I’ll need to rotate it, depending on where I am, but the annoying family in the video showed that that was no problem. And there’s an outlet right there, so the power cord can be stored neatly.

The counter isn’t a good spot for a FaceTime call, but it’ll be easy to move the HomeView over to the kitchen table when I use it for that.

So by being behind the times for several years, I’m now in the perfect position to be on the cutting edge. With a product that’s been sitting on the shelf for a year or so.

First, you should know that I almost never use a word processor. The overwhelming majority of my writing over the past 30 years has been done in a text editor, and its plain text is then fed to some sort of formatting software—Markdown or LaTeX, typically—to set the styles for all the parts. But with one-off documents, the styles I use for blog posts and technical reports don’t make sense. A note for someone who’s coming over to water my plants while I’m out of town shouldn’t look like an analysis of a mobile crane tipover accident. That’s where a word processor comes in handy. It’s much faster to change fonts, sizes, and margins in a word processor than in a LaTeX preamble.

Allison got on my good side early in the article when she complained about the ribbon in Microsoft Word. I think toolbars are way overused in apps nowadays, and Microsoft Office apps are probably the worst offenders. Their ribbons are overloaded with functions that should be in a menu, and they just take up too much space. Fundamentally, I see Microsoft’s ribbons as a user interface cop-out—it’s easier to load up a ribbon with buttons than it is to think carefully about how to make features available when needed without adding visual clutter.

Unfortunately, TextEdit has a toolbar that can’t be hidden. It’s a compact toolbar, to be sure, but almost everything in it could be done through menu commands—as MacWrite and WriteNow managed to do 40 years ago—without taking up any space in the document window. Honestly, who needs buttons for bold and italic? Or left, center, and right justification? This is no better than Word’s buttons for cut, copy, and paste. I really thought TextEdit would have a setting for hiding the toolbar, but I haven’t found one. Control-clicking the toolbar doesn’t let you customize it, either.

Now it’s true that Pages has a toolbar, but it’s tucked up in the title bar where it doesn’t take away space from the document. And you can customize it to include only the buttons you find useful.

Allison is right that the Format sidebar in Pages could use a rethink. Style, Layout, and More are pretty useless names for the settings they expose—calling them One, Two, and Three would be just about as informative. But at least the sidebar can be hidden until you need it.

Another TextEdit deficiency that bothers me is the lack of a sensible zoom control. There are Zoom In and Zoom Out commands in the View menu, but they double and halve the displayed size of the document, which isn’t fine enough control. Would it be so bad to have 25% increments for your users with decaying eyesight?

I mentioned earlier that it’s nice to be able to quickly change styles within a document. It’s also nice to have some standard styles to start with. Pages uses templates, a longstanding Mac feature that may have come over from NeXT, for creating documents with standard styles. It comes with lots of templates that I would never use, but it also lets users create their own. I have a simple one called Big Note, which uses 16-point Helvetica Neue for body text, centered 18-point bold Helvetica Neue for headings, and a 0.75″ indentation for bulleted lists. This works without changes for most of my printed notes to myself and others. While you can create new styles in TextEdit, you can’t save templates.

An advantage of TextEdit that Allison points out and which I concede: TextEdit uses much less memory than Pages. I wish that weren’t the case, but I have a 48 GB MacBook Pro, so I can afford to be profligate with RAM.

Price is not an advantage of TextEdit for me, as I’m using the free version of Pages. If Apple ever forces Pages users to sign up for Creator Studio—which I doubt will happen—I’ll be revisiting TextEdit.

“Easy to follow” does not mean “correct” or “to my liking.” Some of the code in the book simply doesn’t work, and I’ve had to make changes here and there to get it to run. It’s possible that some of the APIs the book relies on have changed their calling conventions, but I also found a pretty obvious off-by-one error. And I’m only three chapters in.

This post, though, is about the “not to my liking” aspect of the code. I feel a little uncomfortable doing this, but I’ve been reading and writing data analysis code in Python for 15–20 years, so I’m going to put my discomfort to the side.

One of the examples used in the book is the well-known iris measurement dataset. There are 150 records in the dataset; here are the first ten:

There are three species of iris in the dataset: setosa, versicolor, and virginica. The records, which are easy to find, are sorted according to class, and it’s necessary to randomize the records for certain operations.

Let’s say the measurements are in a 2D (150×4) NumPy array called x, and the classes, which have been reduced to the integers 0, 1, and 2 for setosa, versicolor, and virginica, respectively, are in a 1D NumPy array called y. Here they are in an interactive Python session:

>>> x
array([[5.1, 3.5, 1.4, 0.2],
       [4.9, 3. , 1.4, 0.2],
       [4.7, 3.2, 1.3, 0.2],
       [4.6, 3.1, 1.5, 0.2],
       [5. , 3.6, 1.4, 0.2],

       [140 other rows],

       [6.7, 3. , 5.2, 2.3],
       [6.3, 2.5, 5. , 1.9],
       [6.5, 3. , 5.2, 2. ],
       [6.2, 3.4, 5.4, 2.3],
       [5.9, 3. , 5.1, 1.8]])
>>> y
array([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
       2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
       2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2])

Kneusel uses NumPy’s integer array indexing to randomize y and the rows of x using the same rearrangement in each. Here’s what he does:

>>> idx = np.argsort(np.random.random(x.shape[0]))
>>> x = x[idx, :]
>>> y = y[idx]

The first line starts by generating an array of 150 (x.shape[0] is 150) random numbers between 0 and 1 via random.random; argsort then returns an array of the indices of the sorted version of that array. So idx is an array of the integers from 0 through 149 in random order. The two lines after that rearrange x and y in that same random order.

I don’t know about you, but I see this as a weird way to go about randomization. I realize you can’t just shuffle x and y individually, as that would break the connection between an iris’s measurements and its class. But why go through two steps when you can create the idx array directly?

>>> idx = np.random.permutation(x.shape[0])

Maybe Kneusel’s method is faster, even though it seems like it should be slower. This won’t matter for the small iris dataset, but he may be preparing his readers for huge datasets to come.

I tested the two methods using IPython’s %timeit magic command. Here’s what I found, with 1,000,000 indices instead of 150:

>>> %timeit np.argsort(np.random.random(1_000_000))
63.8 ms ± 434 μs per loop (mean ± std. dev. of 7 runs, 10 loops each)

>>> %timeit np.random.permutation(1_000_000)
5.98 ms ± 17.8 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

So the simple code is both more direct and about an order of magnitude faster. I’ll be looking at the code in the book with a more critical eye as I proceed—assuming I don’t bail out and look for another machine learning reference.

You may have noticed that the code above uses NumPy’s older random number system. The current approach would be to create a Generator instance and use that as the basis for later function calls. Would this have any effect on the timing results? Let’s see.

>>> rng = np.random.default_rng()
>>> %timeit np.argsort(rng.random(1_000_000))
65 ms ± 188 μs per loop (mean ± std. dev. of 7 runs, 10 loops each)

>>> %timeit rng.permutation(1_000_000)
4.91 ms ± 10.9 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

No, the runtimes are about the same.

I decided to start learning about machine learning a couple of weeks ago. Partly because it sounds interesting, partly because I think I have enough math to handle it, and partly because I felt it was important to have a deeper knowledge if I want to criticize AI.

I started with a library copy of Friedman and Mendhekar’s The Little Learner but decided to drop it after I was about halfway through. Although I was following along reasonably well, I kept struggling with the book’s notation—after 200 pages, I shouldn’t have to keep returning to the front of the book to see what things like $t{|}_i$ mean. If the book’s Scheme code were actually written in Scheme, I might have stuck with it, but its mixture of Scheme with math was too frustrating.

Yesterday I started Kneusel’s Practical Deep Learning. My library gives me free access to O’Reilly ebooks, so it’s easy to have the book open on my iPad while I work through example code on my MacBook. And yes, I certainly feel more comfortable working in Python. But I was surprised by a result pretty early on.

It had to do with calculating the mean values of the columns of a 2D array. The book is explaining a way to normalize (or standardize) a set of data whose features are on vastly different scales. Here’s the code (in an interactive Python session) that does it using the book’s example data:

python:
>>> import numpy as np
>>> x = np.array([
...  [6998, 0.1361, 0.3408, 0.00007350, 78596048],
...  [6580, 0.4908, 3.0150, 0.00004484, 38462706],
...  [7563, 0.9349, 4.3465, 0.00001003,  6700340],
...  [8355, 0.6529, 2.1271, 0.00002966, 51430391],
...  [2393, 0.4605, 2.7561, 0.00003395, 27284192],
...  [9498, 0.0244, 2.7887, 0.00008880, 78543394],
...  [4030, 0.6467, 4.8231, 0.00000403, 19101443],
...  [5275, 0.3560, 0.0705, 0.00000899, 96029352],
...  [8094, 0.7979, 3.9897, 0.00006691,  7307156],
...  [ 843, 0.7892, 0.9804, 0.00005798, 10179751],
...  [1221, 0.9564, 2.3944, 0.00007815, 14241835],
...  [5879, 0.0329, 2.0085, 0.00009564, 34243070],
...  [ 923, 0.4159, 1.7821, 0.00002467, 52404615],
...  [5882, 0.0002, 1.5362, 0.00005066, 18728752],
...  [1796, 0.7247, 2.3190, 0.00001332, 96703562],
... ])
...
>>> xs = (x - x.mean(axis=0)) / x.std(axis=0)
>>> xs
array([[ 0.69308862, -1.12598999, -1.53184967,  0.95258185,  1.18240196],
       [ 0.54647372, -0.01203876,  0.50510857, -0.01928358, -0.1141859 ],
       [ 0.89126426,  1.38267719,  1.51932212, -1.19969655, -1.14033263],
       [ 1.16906091,  0.49704356, -0.17121154, -0.53403994,  0.3047611 ],
       [-0.92213055, -0.10719726,  0.30790249, -0.38856532, -0.47533014],
       [ 1.56997199, -1.47678885,  0.33273415,  1.47140742,  1.18070086],
       [-0.34794732,  0.47757218,  1.88235192, -1.40315756, -0.73969021],
       [ 0.0887406 , -0.43538419, -1.73773921, -1.23496312,  1.7456197 ],
       [ 1.07751429,  0.95242255,  1.24754488,  0.72911384, -1.12072823],
       [-1.46579825,  0.92509981, -1.04466154,  0.42629603, -1.0279233 ],
       [-1.33321348,  1.4501989 ,  0.03239288,  1.11026413, -0.89668956],
       [ 0.30059562, -1.45009422, -0.26155005,  1.70335297, -0.25050967],
       [-1.43773798, -0.24726556, -0.43400063, -0.70325168,  0.33623535],
       [ 0.30164788, -1.55279003, -0.62130451,  0.1780736 , -0.75173073],
       [-1.1315303 ,  0.72253467, -0.02503987, -1.08813209,  1.7674014 ]])

The example data consists of 15 samples, each of which has 5 features. The third command rescales each feature by subtracting its mean and dividing by its standard deviation.

In the book, Kneusel checks the mean of the fourth column of rescaled data to confirm that it’s basically zero. He gets $-1.33\times {10}^{-16}$, which is effectively zero for 64-bit floating point values.

To make sure I was doing things right, I ran this:

python:
>>> xs.mean(axis=0)
array([ 1.48029737e-17, -8.88178420e-17,  6.77698638e-17, -1.62832710e-16,
        4.44089210e-17])

While the fourth mean, $-1.63\times {10}^{-16}$, is certainly as good a zero as the book’s answer, it isn’t the same. To double-check my work, I ran this:

python:
>>> xs[:, 3].mean()
-1.3322676295501878e-16

This is the book’s value. What’s going on?

You may think this is perfectly normal. Floating point numbers are inherently inexact, and as long as I get a result that’s effectively zero, there’s nothing to be bothered about. But I was bothered.

I’m using the same function, mean, from the same library, NumPy, on the same set of data, and I get different answers depending on how I invoke that function. Or maybe I do get the same answers. Here’s another command and its output:

python:
>>> for i in range(xs.shape[1]):
...     print(f'Column {i}: {xs.mean(axis=0)[i] == xs[:, i].mean()}')
...
Column 0: True
Column 1: True
Column 2: True
Column 3: False
Column 4: False

For the first three columns, it doesn’t matter which way I use mean; for the last two, it does.

I should mention here that while the different results are obvious when the mean is close to zero, this behavior is present when operating on any 2D array. I’ve tried it out on several 2D arrays made from randomly generated floating point numbers.

During these experiments with randomly generated arrays, I got the sense that the likelihood of getting the same mean both ways got smaller as the number of rows in the array got larger. I decided to check that out with this script:

python:
 1:  #!/usr/bin/env python3
 2:  
 3:  import numpy as np
 4:  
 5:  rng = np.random.default_rng()
 6:  
 7:  N = 5000
 8:  
 9:  for n in (10, 100, 1000, 10_000, 100_000):
10:    count = 0
11:    for i in range(N):
12:      x0 = rng.uniform(low=0, high=100, size=n)
13:      x1 = rng.uniform(low=100, high=200, size=n)
14:      x = np.column_stack((x0, x1))
15:      if x.mean(axis=0)[0] == x[:, 0].mean():
16:        count += 1
17:      if x.mean(axis=0)[1] == x[:, 1].mean():
18:        count += 1
19:    print(f'n = {n:,d}')
20:    print(f'  Same means: {count/(2*N):.2%}')

The results were

n = 10
  Same means: 73.97%
n = 100
  Same means: 28.47%
n = 1,000
  Same means:  7.47%
n = 10,000
  Same means:  2.50%
n = 100,000
  Same means:  1.03%

So arrays with more rows are less likely to yield the same mean values when the mean function is used in these two different ways.

My working theory is that when I use mean() on a 1D array extracted from a 2D array, the computations are done differently than when I use mean(axis=0) on the 2D array. Mathematically the same, but computationally different. Maybe it’s as simple as the summation being done in a different order so the partial sums round off in slightly different ways. The more partial sums, the greater the likelihood of a different answer.

Ultimately, $-1.33\times {10}^{-16}$ and $-1.63\times {10}^{-16}$ are both zero, so this was mainly an exercise in satisfying my curiosity. I worry when computer results that ought to be exactly the same are only nearly the same. It usually means I’ve done something wrong, but apparently not in this case.

Let’s say I was trying to add Applied Elasticity by Timoshenko and Lessells.¹ If you go to the LoC’s MARC record for the book and click on the Download link, you’ll see a popup that looks like this:

So it looks like you can click the MODS link to get the MODS file for the book. That’s the file my script parses to get the information to add to the database. The MODS link for this book is

https://lccn.loc.gov/26010978/mods

which is the URL form that lccn2library expects. Unfortunately, that link returns an empty file. And not just for that book, but for every book I tried. What does the little northeast-pointing arrow mean? Beats me. You’d think it was an indication that the MODS link was pointing to some external site, but that’s not the case.

Maybe I’ve caught the LoC in the middle of a transition to a new system for storing records in various formats. Maybe I’ll return in a month or two to find that everything is working again—perhaps with new URLs for the different formats. I hope so.

But until that hoped-for day, I’m pissed at the LoC because I have to add books to my database by hand using the sqlite3 interactive command-line tool. Which is slow but not terrible, especially since I’m adding only a book or two at a time.

The command to add a new book to the database is

INSERT INTO book(title, subtitle, volume, edition, publisher, published, lccn, loc, added)
VALUES(<list of values separated by commas>);

The book will be assigned an ID automatically. To get it, I run

SELECT id,title FROM book WHERE added IS "2026-10-08";

The first field in the output will be the ID. The date must be a string with the current date in yyyy-mm-dd format.

SELECT last_insert_rowid();

SELECT max(id) from book;

The new book may be written by an author already in the database. To check if that’s the case, I run

SELECT * FROM author WHERE name LIKE "%<portion of name>%";

If the author’s already in the database, that command will return their ID. If not, it returns nothing. I then run

INSERT INTO author(name) VALUES("<full name>");

and then the SELECT command above to get the author’s ID.

The final step is to add a record to the book_author table to tie the book and author together. That’s

INSERT INTO book_author(book_id, author_id) VALUES(<book ID>, <author ID>);

As I said, this is slow because it’s several steps, but none of the steps are difficult.

What will I do if the LoC never fixes the problem of the missing MODS files? I suppose I could parse the MARC records, which are still accessible, but that would be a pain in the ass. Maybe I’ll build a little interactive script where I can just type in the necessary information and have the script generate and run the SQL commands. I hope it doesn’t come to that.

I figured it was worth a quick post to show how I made it.

I had already done most of the work back in 2022 in a Mathematica notebook I made to support my original orbital curvature post. So I copied the pertinent calculations from that notebook, pasted them into a new one, and made the adjustments necessary to produce the plot. Here’s the new notebook:

The bottom half of the notebook is where the plotting commands are. The key items are:

• The definitions of xGrid, xTicks, yGrid, and yTicks. These produce lists of values used to lay out the grid spacing and tick mark labels. Most of this is self-explanatory, but I do want to call out the use of NumberForm to format the tick labels with two decimal places. NumberForm[x, {3, 2}] is very much like Python’s {x:3.2f} in an f-string. Like most things in Mathematica, it’s kind of verbose, but it is readable.

• The call to ParametricPlot includes the option

  AspectRatio -> .25/.05
  

  AspectRatio sets the ratio of height to width for the plot as a whole, so the value I set it to was based on the ratio of the values given in the PlotRange option. The overall plot is 0.25 units high and 0.05 units wide, so to make the x and y units the same size, AspectRatio is set to that ratio. I entered it as a division instead of as the number 5 because I wanted the reasoning behind it to be clear. I suppose I could have been even more explicit by saying

  AspectRatio -> (.25 - 0)/(1.01 - .96)
  

  but there are limits to my verbosity, even when using Mathematica.

To get the image out of the notebook, I right-clicked on it, selected Save Graphic As… from the popup menu, and chose SVG as the format. That’s why the plot stays smooth if you zoom in on it.

For much of the article, Allain complains about how the orbit of the Moon as it and the Earth make their way around the Sun is often distorted in textbooks. Like this, which is a frame from an animated GIF in the article.

In this image, the Earth-Moon distance is exaggerated, and it looks like the Moon curves away from the Sun when it’s between the Earth and the Sun. To show that this is wrong, he plots portions of the Moon and Earth orbits without exaggerating the Moon-Earth distance:

Forgive me, but what the actual fuck? How can you spend over 1000 words complaining about graphical distortions and then produce this? Sure, it’s not the same distortion he was complaining about, but still. The whole point of the article was to show that the Moon’s path over the course of an Earth year is a sort of wobbly circle around the Sun. The arcs in this plot are nowhere near circular.

Here’s a properly scaled version of Allain’s plot:

Yes, the plot is really tall and skinny. It has to be to avoid distorting the paths. Note that the grids are square and represent the same distance in each direction.

We all know how this happened. The range of the x data is very small compared to the range of the y data, but because the plotting software defaults to a landscape-style graph, the paths come out looking like arcs of very wide ellipses. Unless the person running the software steps in to make sure x and y distances are drawn to the same scale.

I could write a post like this almost every day. So many people accept the defaults of their graphing software without thinking about how one or two small tweaks could make their plots so much better.

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

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

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

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

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

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

And then there’s the best one:

• The chairs are facing away from the table.

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