The wait for new Siri continues
November 4, 2025 at 4:25 PM by Dr. Drang
Yesterday, I drove to Champaign-Urbana for the Illinois men’s home basketball opener. Because I’m going to the CSO concert tonight, I stayed here overnight. When I started my car this morning, CarPlay connected to my phone and offered to give me directions home. Snort.
It’s common for CarPlay to do this when I’m away from home, and under most circumstances it’s a reasonable suggestion. A couple of years ago, when my wife was having day-long chemo infusions at the University of Chicago Medical Center, it was nice to have our rush hour route automatically plotted from Hyde Park home to Naperville. But I’m obviously not going home today until after the concert.
Should Siri know this? Well, the concert ticket is in my Wallet, the event (with location) is in my Calendar, and the email with a link to the ticket is archived somewhere in Mail. Last year’s Apple Intelligence ads would lead anyone—anyone who didn’t keep track of Siri’s actual capabilities, that is—to think that suggestions given by an Apple device would be precise and personalized. But even people who don’t follow Apple closely know that last year’s ads were lies.
We’re now hoping that Mark Gurman is right and a bespoke version of Google Gemini will be the savior of personalized Siri, giving us an assistant that’s aware of our calendar, contacts, and so on, but doesn’t transmit all our data to the don’t be evil empire in Mountain View.
Or maybe we shouldn’t bother. If Apple hadn’t made promises it couldn’t keep, today’s suggestion to drive home wouldn’t have struck me as funny. I’d be happy when suggestions like that are right and would dismiss them without a second thought when they’re wrong. It’s the hope that kills you.
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.1 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.
-
In case you’ve forgotten, Apple’s fiscal year ends on the last Saturday of September, so Q1 2019 covers roughly October through December of 2018. ↩
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 and the width as , I defined the wavy path as
where the axis runs along the bottom edge of the road, and the axis runs across the road.
A differential length of arc is
Integrating this from to 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 , , and plugging in different values of until I got a result of , which is, as you might recall, the distance my watch gave as I finished the race.
The answer I got was . Here’s the Mathematica code that got me there:
This is slightly less than the 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
where
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 as before.
In polar coordinates, differential arc length has a more complicated definition:
Numerical integration of this over from to with different values of led to a solution of to get a path length of . Here’s a screenshot of the Mathematica code:
I used t for because it’s easier to type.
That this value of 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.