And now it’s all this

I just said what I said and it was wrong
Or was taken wrong

The problem with dollars

November 1, 2025 at 9:08 AM by Dr. Drang

I stopped charting Apple’s quarterly results back in 2019 and don’t intend to return to it, but after seeing the recent posts at Six Colors and TidBITS, I thought I’d try out a new graph.

I got out of the Apple charting business shortly after Apple stopped reporting unit sales with the Q1 2019 figures.¹ I care more about how many products Apple is putting into people’s hands than about how much money is passing from those hands into Apple’s pocket. I mentioned this in my penultimate quarterly charting post, and I also pointed out a problem with charting dollar sales instead of unit sales:

One unaddressed problem with [Apple’s revenue figures] is that they don’t account for inflation—something I didn’t have to worry about when I was plotting unit sales. Apple doesn’t account for inflation either, of course, but that doesn’t mean I shouldn’t. If I’m going to keep doing this, I’ll have to decide on an inflation index and a basis year.

Of course, I didn’t decide on how to handle inflation. I chickened out and stopped doing quarterly posts after just one more set of charts. And Apple is happy to ignore inflation, because doing so allows it to report most quarters as “the best ever” in one form or another.

But let’s adjust Apple’s numbers for inflation and see what happens. For simplicity, I’m going to use the CPI-U Index, a common measure of inflation. It looks like this from 2018 to the present:

I downloaded the CPI-U monthly values from the Bureau of Labor Statistics and adjusted Apple’s revenue figures to their equivalent in Q1 2019 dollars. Here’s how that looks compared to the unadjusted revenue:

After adjustment, the climb after the big work-from-home jump isn’t as impressive, although the non-Q1 quarters of fiscal 2025 are quite good. The just-reported Q4 revenue truly is the best Q4 ever, even after adjustment.

You might say that CPI-U isn’t the right inflation measure to use. Also—as Jason Snell pointed out when I showed him this graph—Apple is a worldwide company, and there are different inflation rates in every country. But some adjustment should be made, especially if you want to graph results over several years and some of those years include the COVID inflation period. I’ve chosen the CPI-U because Apple reports its earnings in US dollars, and that’s the inflation metric most Americans are used to seeing.

This isn’t to say that it’s wrong to report the unadjusted numbers, just that accounting for inflation gives some added perspective. Does this mean I’m suggesting additional work for others that I myself don’t intend to do? Yes.

---

Vectors and weathervanes

October 29, 2025 at 12:51 PM by Dr. Drang

Before going out for a bike ride this morning, I checked the Weather app to see the speed and direction of the wind. On days with a decent wind, I prefer to ride out against the wind and come back with it. Here’s what the app showed:

So I left my house and went east, but my ride is not what this post is about. It’s about the image in the Wind section of the screenshot and why I have to think carefully before making any decisions based on it.

The wind image is an arrow on top of a compass, and the arrow is oriented to point in the direction that the wind is blowing. It’s like a vector representation of the wind, except that the wind speed isn’t given by the length of the arrow, it’s written explicitly at the center of the compass. Apple is like many other weather apps in showing the wind with an arrow like this.

The problem I have—and I realize this is my problem, not Apple’s—is that when I see an image like this, my first thought is of a weathervane.

Good Directions weathervane image from Amazon.

The arrow on a weathervane points into the wind, not with it, because the arrowhead is smaller than the fletching. If Apple’s wind image were a stylized weathervane rather than a vector, it would be pointing in the opposite direction. This is why I have to think twice about wind direction.

The terminology we use for wind direction is clearly based on weathervanes. This morning’s wind is described as east-northeast (ENE)—the direction a weathervane would be pointing. It’s possible that Apple puts a dot at the tail of the wind vector to have something that matches the text. Unfortunately for me, the dot makes the arrow look even more like a weathervane, forcing me to think harder. It would be better if I could just read the text in the left half of the Wind section, but I can’t. The image draws my attention.

Which reminds me of something. About a week ago, I was riding my bike along the Centennial Trail from Romeoville to Willow Springs. The wind was strong and gusty from the south. As I went along the Chicago Sanitary and Ship Canal by the Lemont Shipyard, the boom of a tower crane extended over the bike path.

Obviously, the tower crane wasn’t moving any cargo onto or off of the bike path. It had swung into that position because of the wind. Tower cranes aren’t supposed to be used in high winds, and operators are trained to disengage the gearing to allow them to swing with the wind, reducing the force that would overturn them. This is sometimes called “weathervaning,” even though the business end of the boom points with the wind (like Apple’s arrow) instead of into the wind.

By the way, here’s where that photo was taken, and you can see why a south wind would push the boom into the position shown. This portion of the bike path runs between the Des Plaines River and the canal. Another canal, the historic (and much smaller) Illinois and Michigan Canal, is south of the Sanitary and Ship Canal.

Don’t get the I&M Canal confused with the Hennepin Canal. Unlike the Hennepin Canal, the I&M Canal was an economic success, but very little of it can be kayaked nowadays—too shallow and too filled with downed trees. Its towpath has been turned into a great bike path, though. A few miles north of Lemont, I switched from the Centennial Trail to the John Husar Trail, crossing over the Sanitary and Ship Canal to finish my ride along the I&M Canal.

Today’s ride was nice, but distinctly chillier than last week’s. I’ll soon be hanging up the bike until spring.

---

Other wavy paths

October 28, 2025 at 12:25 PM by Dr. Drang

I got some good replies on Mastodon after Saturday’s post. Longtime friend of the blog Nathan Grigg said he’s always assumed that GPS-measured lengths would be long because no matter how straight your path, the GPS error would make it zigzagged. Then wherami and thvedt pointed out that the official rules of these events say that the race’s distance is supposed to be measured along the shortest path. If the road is curving left, it should be measured along the left edge; if the road is curving right, it should be measured along the right edge. This makes sense, as you don’t want runners to be able to run less than the official distance. The result is that basically everyone goes farther than the official course distance.

As you can see from this Fitness app screenshot of my route, the 5k at the Morton Arboretum has both right and left curves, so the route measurement must be done carefully if it’s to be by the rules.

I began thinking about calculating the length of a zigzag path along a road that went in a circuit. The simplest circuit is a circle, and I thought it would be easier to define my path as a sinusoid within the roadway. Like this:

Following the principle that you should walk before you run, I started with a simpler problem: a sinusoidal path along a straight road.

Taking the length of the road as $d$ and the width as $w$, I defined the wavy path as

$$y=\frac{w}{2}(1-\cos \frac{n\pi x}{d})$$

where the $x$ axis runs along the bottom edge of the road, and the $y$ axis runs across the road.

A differential length of arc is

$$ds=\sqrt{d{x}^2+d{y}^2}=\sqrt{1+{\left(\frac{n\pi w}{2d}\right)}^2{\sin }^2\frac{n\pi x}{d}}dx$$

Integrating this from $0$ to $d$ gives us the length of the wavy path. This can be done through elliptic integrals, but I’ve never felt comfortable with them, so I just did it numerically, using $d=5000$, $w=5$, and plugging in different values of $n$ until I got a result of $5070$, which is, as you might recall, the distance my watch gave as I finished the race.

The answer I got was $n=151.5$. Here’s the Mathematica code that got me there:

This is slightly less than the $n=167.9$ I got in Saturday’s analysis, where I took the path to be a series of straight-line segments. The lower number for a sinusoid makes sense. The path distance from one edge of the road to another is longer when following a sinusoid than when going in a straight line, so it takes fewer zigs and zags to get to a particular distance.

Now let’s tackle the problem of a wavy path along a circular road. Polar coordinates seem like our best bet for this. We’ll define the radial coordinate of the wavy path as

$$r=(r_i+\frac{w}{2})-\frac{w}{2}\cos \frac{n\theta }{2}$$

where

$$r_i=\frac{5000}{2\pi }$$

is the radius of the inside edge of the circle, the circumference of which is the 5000 m length of the race. We’ll use $w=5$ as before.

In polar coordinates, differential arc length has a more complicated definition:

$$ds=\sqrt{d{r}^2+(rd\theta {)}^2}=\sqrt{{\left(\frac{nw}{4}\right)}^2{\sin }^2\frac{n\theta }{2}+{[(r_i+\frac{w}{2})-\frac{w}{2}\cos \frac{n\theta }{2}]}^2}d\theta$$

Numerical integration of this over $\theta$ from $0$ to $2\pi$ with different values of $n$ led to a solution of $n=133.4$ to get a path length of $5070$. Here’s a screenshot of the Mathematica code:

I used t for $\theta$ because it’s easier to type.

That this value of $n$ is smaller than for the straight road makes sense because all of the path is beyond the inner edge of the roadway. The waviness is centered on a path that’s already longer than the course.

I suppose I could have set up iterative solutions in Mathematica to get the values of n that led to path lengths of 5070. But NIntegrate worked so quickly that it was faster to just work my way to n via trial-and-error.

I should also mention that Mathematica has an ArcLength function, which seemed at first like the right way to go. But it was extremely slow, possibly because it was trying to get an analytical solution. By doing a little thinking to get the equations for the differential arc length, I saved myself a lot of time.

---

Zigzag 5k

October 25, 2025 at 2:43 PM by Dr. Drang

I did the Fall Color 5k Run and Walk at the Morton Arboretum this morning. I say “did” to downplay the fact that I don’t run races like this, I walk them. I got terrible shin splints 20+ years ago and haven’t run more than a few hundred meters at a time since then. But I do try to walk at a decent clip. My goal is to do these races in under 45 minutes, and I managed that this morning. Here’s a screenshot of my watch as I crossed the finish line.

The time of 43:38 matched my official time to the second, so I’m confident the start/stop I did on my watch was accurate. What’s off, though, is the distance. My watch says I went 70 meters more than 5k. How can that be?

The obvious answers are that either my watch is slightly off through an accumulation of small GPS errors or the course distance is slightly off because it wasn’t measured perfectly. Could also be some combination of both.

But these answers—although probably right—are dull and don’t let me try out any calculations. Because I started the race late (very long traffic backup at the entrance; also today was the first time I slept past 6:30 for as long as I can remember), I had to pass a lot of people on the route. Could it be that my zigzag path along the road through the Arboretum added 70 meters to my walk?

Let’s simplify the problem to make it tractable. Imagine a straight road 5 m wide and 5000 m long. I take a zigzag path down the road, with each zig and zag of the same length and the full width of the road. How many of these zigzags are needed to end up with a path length of 5070 m, and is that answer reasonable?

We’ll take $n$ as the number of zigs and zags, so

$$d=na$$

The total length of my walk is

$$\ell =n\sqrt{a^2+b^2}=n\sqrt{\frac{d^2}{n^2}+b^2}=\sqrt{d^2+n^2{b}^2}$$

With $d=5000\mathrm{m}$, $b=5\mathrm{m}$, and $\ell =5070\mathrm{m}$, what is $n$?

Since

$${\ell }^2=d^2+n^2{b}^2$$

we can solve for $n$:

$$n=\sqrt{\frac{{\ell }^2-d^2}{b^2}}$$

Now, when you’re taking the difference of two numbers that are relatively close to one another, you’re supposed to be careful about losing significant digits. Here, $\ell$ and $d$ differ by enough that we really don’t have to worry about that, but let’s be good boys and girls anyway.

Rewrite $\ell$ as

$$\ell =d+ϵ$$

Then

$${\ell }^2=d^2+2dϵ+{ϵ}^2$$

and

$${\ell }^2-d^2=2dϵ+{ϵ}^2$$

so

$$n=\sqrt{\frac{2dϵ+{ϵ}^2}{b^2}}$$

and we won’t lose any significant digits because we’re adding, not subtracting.

Plugging in the numbers, we get

$$n=\sqrt{\frac{2\cdot 5000\cdot 70+{70}^2}{5^2}}=167.9$$

Is it reasonable to think I zigged and zagged 168 times? No. That’s one full crossing of the road every 30 meters or so, which is ridiculous.

So we’re left with the duller but more reasonable answer that my 5.07 km distance is some combination of measurement errors. Disappointing.

---

Older posts

Site search

Meta

• drdrang at leancrew
• Blog archive
• RSS feed
• JSON feed
• Mastodon
• GitHub repositories

Recent posts

Credits

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

© 2005–2025, Dr. Drang