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.

This short video appeared in my YouTube feed last week. It’s from Hannah Fry, whom you probably know from her appearances on Numberphile and other STEM-oriented stuff. If you’re in the UK, you’ve may have seen her on the BBC, too.

The short presents a classic problem in conditional probability, but the answer she comes up with is wrong. It’s a good estimate, and it’s the same answer I got when I stopped the video and tried to work it out in my head, but it’s still wrong. By just a little bit.

Here’s the problem: There’s a disease that affects 1 in 1,000 people. A test for the disease is perfect in one sense but imperfect in another. If you have the disease, the test will return a positive result 100% of the time. If you don’t have the disease, the test will return a negative result 95% of the time but a positive result 5% of the time. If you have the test and the result is positive, what is the probability you have the disease?

What makes this a classic problem is that it presents you with conditional probability in one sense (the probability of a positive test given that you have the disease) and asks for a conditional probability in the opposite sense (the probability that you have the disease given that your test was positive). The solution combines the definition of conditional probability, the commutative property of intersections, and the law of total probability.

Let’s define some events. $D$ is you having the disease, and $T$ is you getting a positive test result. Putting a horizontal bar over these indicates not having the disease and not testing positive (i.e., testing negative), respectively. Therefore

$$\begin{array}{cc}\hfill P(D)& =0.001\hfill \\ \hfill P(\stackrel{—}{D})& =0.999\hfill \\ \hfill P(T\mid D)& =1\hfill \\ \hfill P(\stackrel{—}{T}\mid \stackrel{—}{D})& =0.95\hfill \\ \hfill P(T\mid \stackrel{—}{D})& =0.05\hfill \end{array}$$

The vertical bars are read as “given,” meaning the event after the bar is the condition. What we’ve been asked to find is $P(D\mid T)$. Let’s work it out.

By the definition of conditional probability, we can say

$$P(D\cap T)=P(D\mid T)P(T)$$

where $\cap$ means the intersection of the two events. So

$$P(D\mid T)=\frac{P(D\cap T)}{P(T)}$$

Because the intersection of events is commutative

$$P(D\cap T)=P(T\cap D)=P(T\mid D)P(D)$$

Both terms on the right-hand side of this equation are known, so we can say

$$P(D\mid T)=\frac{(1)(0.001)}{P(T)}$$

Since $D$ and $\stackrel{—}{D}$ are mutually exclusive and collectively exhaustive, the law of total probability says

$$\begin{array}{cc}\hfill P(T)& =P(T\mid D)P(D)+P(T\mid \stackrel{—}{D})P(\stackrel{—}{D})\hfill \\ \hfill & =(1)(0.001)+(0.05)(0.999)\hfill \\ \hfill & =0.05095\hfill \end{array}$$

So

$$P(D\mid T)=\frac{0.001}{0.05095}=0.019627$$

which is, as I said, pretty close to the 2% answer in the video but not exactly.

This formal approach is how you’re taught to solve problems like this in an introductory probability class, but Dr. Fry and I used a more concrete method to get our nearly correct answers. Here’s what we did:

Imagine 1,000 typical people. Of these, 1 should have the disease (correct) and 50 should test positive (incorrect). That tells us that 1 in 50, or 2%, of the people who test positive will have the disease. Here’s a screenshot from the video that matches this calculation:

What makes this calculation wrong is that it implicitly assumes that 5% of everyone will test positive, not 5% of only those who don’t have the disease. The number who will test positive should be 5% of 999, which is 49.95, plus the 1 who does have the disease. So 1 in 50.95, or 1.9627%, of those who test positive will have the disease. This answer matches that of the formal approach.

This is somewhat unsatisfying, though, as the purpose of this “imagine a bunch of typical people” method is to have all the people counts be integers. Although the numbers work out when you get to the end, it’s distracting to litter the discussion with fractional people. You can get around this by imagining more people—a million, say—but then all the numbers get bigger: 1,000 people with the disease and 49,950 false positives. This isn’t a problem for the kind of people who read this blog but isn’t so great for the more general audience Dr. Fry is addressing.

Personally, I would have been OK with her saying that 5% of 999 is almost 50, so the number who test positive is nearly 51. And 1 out of 51 is just under 2%—call it 2% in round figures. You still make the point that it’s way less than 95% and that problems like this require some care.

That someone in the glorious Bartlet White House believes in nonsense isn’t what bothers me. Lots of smart people believe silly things. What’s wrong is that it’s C.J., the primary female character, who believes in superstition while the men around her are pooh-poohing it. I’m sure plenty of women will tell me that’s par for the course for Aaron Sorkin, but it still bothers me.

There are two small counters to the general sexism of the egg subplot. First, the men who tell C.J. she’s full of it are themselves wrong. They think you can’t balance an egg on its end, even though it’s not really that hard.

This photo was taken today (yes, on the equinox but not the vernal equinox and not at the exact moment) on my back patio. I didn’t do any tricks like slightly crack the shell or put it on a bit of salt and then blow the salt away. I just kept adjusting its position again and again until it stood. The plain fact is that it just takes a little time to balance an egg on its end, time that most people aren’t willing to spend. (And yes, it helps to have a rough surface.)

The second counter is that Jed seems willing to believe the egg story. He doesn’t defend C.J., but he does try to stand an egg on end in his office. In some ways, this is worse. For all his faults, Jed is supposed to know at least a bit about science. Remember the episode in which C.J. has to remind him to let the NASA experts handle the science questions coming in from schoolkids? If anyone should be instantly dismissive of the standing egg myth, it should be Jed.

At the very end of the show, C.J.’s alone and manages to balance an egg on its end, justifying her faith. The title comes from Hebrews 11:1, which she recites earlier in the episode. I guess this is supposed to get us to think that she hasn’t been spouting nonsense all this time, but what it really means is that she can do what anyone can do if they take their time.

What bothers me the most is the setup for her balancing act. Before trying, she looks pointedly at the clock, which shows midnight. Recall that the balancing is supposed to work only at the exact moment of the equinox. Does Sorkin think equinoxes always occur at midnight? Does he think the audience is dumb enough to believe that? The episode aired in April 2003, so I guess its events take place on March 20 of that year. In Washington, the 2003 vernal equinox occurred at about 8:00 pm, not four hours later. Was the show set a year or two earlier? No midnight spring equinoxes those years, either.

If you’re interested in the history of the egg balancing myth, Martin Gardner wrote an article about it in 1996. You can see the text on the Wayback Machine.

This video Matt Parker posted a couple of days ago really pissed me off:

It’s cheating to say that a result arrived at through classical mechanics—in this case, that $\frac{1}{2}m{v}^2$ is the kinetic energy of a particle—is wrong because it’s only an approximation to relativistic physics. Of course that’s the case, and I swore at my phone when the “reveal” came.

By the end of the video, though, I had calmed down because I knew I could put together a quick post of my own by rewriting the infinite series equation he derived in a better form. Also, I could provide a general expression for the individual terms.

Let’s start with this result: that the kinetic energy of a particle (including relativistic effects) is

$$m{c}^2(\gamma -1)$$

where m is the mass of the particle, c is the speed of light, and

$$\gamma =\frac{1}{\sqrt{1-\frac{v^2}{c^2}}}$$

is the Lorentz factor, with v as the velocity of the particle. The video gets to this result at about the 8-minute mark.

Matt then does a series expansion of the $\gamma$ term to get

$$\gamma =1+\frac{1}{2}\frac{v^2}{c^2}+\frac{3}{8}\frac{v^4}{c^4}+\frac{5}{16}\frac{v^6}{c^6}+\frac{35}{128}\frac{v^8}{c^8}+\dots$$

The leading 1 of this series gets canceled by the 1 that’s subtracted from γ, giving

$$\frac{1}{2}m{v}^2+\frac{3}{8}m\frac{v^4}{c^2}+\frac{5}{16}m\frac{v^6}{c^4}+\frac{35}{128}m\frac{v^8}{c^6}+\dots$$

for the kinetic energy. The leading term is the one we get from classical mechanics and the others are essentially zero unless you’re in a particle accelerator (which is discussed later in the video).

I don’t like this form for the equation. It’s cleaner if you factor out all the terms that give the expression the units of energy and then have a nondimensional expression afterward. Like this:

$$\frac{1}{2}m{v}^2(1+\frac{3}{4}\frac{v^2}{c^2}+\frac{5}{8}\frac{v^4}{c^4}+\frac{35}{64}\frac{v^6}{c^6}+\dots )$$

Isn’t this nicer? The expression in the parentheses is a function of the ratio of the velocity of the particle to the speed of light. If we call that

$$\varphi =\frac{v}{c}$$

then the kinetic energy is

$$\frac{1}{2}m{v}^2(1+\frac{3}{4}{\varphi }^2+\frac{5}{8}{\varphi }^4+\frac{35}{64}{\varphi }^6+\dots )$$

and it’s much easier to see why the terms after the 1 are vanishingly small for most situations—all the situations for which classical mechanics applies.

One last thing. Matt sort of explained how to calculate the terms of the expansion of γ in the companion video, but there was a lot of handwaving and he bailed out after the second term. It doesn’t take too much effort to show that the series expansion of γ can be written like this:

$$\gamma =\sum _{n=0,2,4,\dots }^{\infty }\frac{n!}{2^n{\left[\left(n/2\right)!\right]}^2}{\varphi }^n$$

That means the kinetic energy, $m{c}^2(\gamma -1)$, is

$$\frac{1}{2}m{v}^2\sum _{n=2,4,6,\dots }^{\infty }\frac{n!}{2^{n-1}{\left[\left(n/2\right)!\right]}^2}{\varphi }^{n-2}$$

You can confirm that these terms match the equation we saw earlier by plugging values of n from 2 through 8 into this expression. And now we can extend the series as far as we like, even though the additional terms add essentially nothing.

You can click on it to see a 300 dpi version. The Apple page linked above will give you infinite-resolution PDFs.

When I zoomed in on Stephen’s page, I was initially confused, but then I realized what seemed odd to me. You see, I’ve spent an awful lot of the past 40 years looking at engineering drawings, and I can’t think of any that looked like this. That’s because the drawings I’m used to are for making the depicted product, but the drawings Apple’s offering up here aren’t for that.¹ These are for others—not Apple and not its suppliers—to use for making cases and other accessories. I figured it was worth a quick post on what makes a drawing like the one above so different from what I’m used to.

First off, there are so many dimensions. Drawings of full products are typically called assembly drawings, and they have almost no dimensions. What they do is show how the various component pieces (subassemblies) are put together. The subassemblies have their own drawings that show how they are put together from their components, which are themselves typically subassemblies. Eventually, you get down to the individual part drawings, which depict a single piece of metal or glass or plastic. At each level in this hierarchy, the drawings tend to include only the dimensions necessary to build the object depicted. You don’t include the length and diameter of a screw on an assembly drawing; you simply call out its part number (which is also its drawing number).

Speaking of drawing numbers, if you look in the title block you’ll see that there is no drawing number. Design drawings always have these. They also have the names or initials of the draftsmen and checkers and, usually, a list of revisions. These public drawings don’t reveal any of that internal information.

There are names for many of the items and dimensions: product length, display active area, volume button, rear sensor, etc. These are not common in design drawings because they tend to be of no value to those doing the manufacturing. You don’t need to know what this hole is for; just make it this big and put it here.

Which leads us to tolerances, which are absent. Dimensions and positions are given to the nearest hundredth of a millimeter and there is no give or take. To the outside world, Apple’s dimensions are absolute and invariable. Inside Apple and its suppliers, people know better.

Also absent is any specification of material, other than a few generic mentions of glass. While assembly drawings don’t usually include materials, parts drawings always refer to material specs, usually included in another company document.

The last thing I’ll mention is the Notes section in the upper left corner. It has instructions clearly meant for people outside of Apple and making accessories. If I’d zoomed in on this section first, I probably wouldn’t have been even momentarily confused.

First came Live Rewind, a feature that lets you “go back in time” to pick up on something you missed that was said in the past 15 seconds. Here’s how Apple describes it on the website:

Live Rewind catches what you missed. Did someone say something you couldn’t hear in a loud restaurant or share cooking instructions you didn’t quite catch? Just double-click the Digital Crown, and Live Rewind transcribes what was said in the last 15 seconds. You can ask Siri about the content of the transcript or save it to the new Siri app to revisit later.

In the Event, this was illustrated by a waitress going through the restaurant’s specials too quickly for the diners to remember all of them. One of the diners double-clicks the crown on his watch and reads what she said.

It seems like your watch will be listening continuously, keeping the last 15 seconds in a buffer, ready to be transcribed when you ask. That’s fine for you, because you know it’s happening, but what about those around you? Did they agree to this? I doubt wait staff will be upset with their spiel being transcribed, but the idea behind Live Rewind seems to be that everyone and everything near your watch is being recorded for 15 seconds. Surely, some people wouldn’t consent to that if they were asked. Significantly, though, they’re not being asked. I’m sure Apple will argue that there’s no privacy issue because the recordings aren’t being saved. But if there’s a transcription, isn’t that a type of saving?

And then there’s the question of legality. A great variety of law, both in the United States and across the world, concerns the recording of electronic and in-person conversations. I’m sure Apple has considered this, but I have to think some jurisdictions will frown on Live Rewind. If Apple has to defend it, that’s fine. What’s one more squadron of lawyers to Apple? But if an Apple Watch owner has to defend a transcription made innocently—made with Apple’s encouragement, in fact—that seems like an unfair burden. Maybe Apple should indemnify all future Watch buyers from privacy-related legal action.

Right after Live Rewind, we get the introduction of Siri Recap. From the Series 12 web page:

Siri Recap can summarize your chats to refresh your memory. Siri Recap transforms your conversations into high-level notes, so you can stay focused and present. Each Siri Recap includes a title, a summary, and key points that you can review in the Siri app on your Apple Watch or iPhone. You can turn Siri Recap on or off at any time from Control Center or choose where and when it takes notes, such as only at work or never at night.

Siri Recap does a summary, not a transcription, and it’s not automatic the way Live Rewind is, although it does sound as if you can set it up to always record when you’re at a certain place, so that’s kind of automatic. Apple touted Siri Recap’s privacy with three bullet points:

I think Apple is slicing the baloney pretty thin when it says audio isn’t recorded. Surely there’s some recording because summaries require context; they can’t be made on the fly. Maybe a transcription is done in near-real time and the summary is drawn from that. If so, the transcription is a type of recording, albeit one that isn’t stored after the summary is made. As for not identifying the speakers, I don’t see how that matters. Old-fashioned audio recordings don’t identify speakers, either, but they’re still intrusions on the speakers’ privacy if they didn’t give consent.

Apple has always focused on the privacy of its customers: your information is encrypted, your data stays on your device. It’s following that same pattern here, but the privacy concerns of Live Rewind and Siri Recap aren’t limited to the owners of Apple Watches. Apple now needs think about the privacy of non-customers and be able to explain how that’s being protected, too.

And while an argument can be made that textual transcriptions and recaps aren’t as invasive as saved audio recordings, that doesn’t mean they aren’t invasive at all. That little lock animation Apple’s been using to describe its commitment to privacy has been very effective, but its binary nature doesn’t fit when the products start putting privacy on a sliding scale.