MathML problems in Mobile Safari

Sometime in the early evening on Sunday, I looked at that day’s Antikythera post on my phone and saw that two of the equations weren’t rendering:

Antikythera page rendered in Safari

This was in Safari. I hadn’t seen the errors before publishing because I’d done all the writing and test viewing on my Mac, and Safari on the Mac rendered the equations just fine. There wasn’t anything wrong with the MathML used to make the equations—it’s hard to make a mistake in equations as simple as those—and I hadn’t heard any complaints from readers, even though seven or eight hours had passed since the post was published. I decided to ignore the problem. Maybe there was something on my phone that was causing me to have a unique issue. I put my phone away and started watching Get Back on Disney+.

But problems typically don’t go away on their own, do they?. When I checked Mastodon later that night, there was a message from tambourineman saying that he was seeing the same error messages on his phone. So the problem wasn’t just with me. And since his phone was running iOS 17.6.1, the rendering issue wasn’t something that appeared in a recent iOS/Safari update.

I opened the page on my iPad and saw the error there. Then I installed Arc, Chrome, Edge, and Firefox and looked at the page in each of them. No errors. Here’s the same portion of the page in Firefox on my phone:

Antikythera page rendered in Firefox

At this point, I felt it was too late for me to make any progress in solving tambourineman’s problem, but in the jingle jangle morning I came back to it.

There’s always been a ragged clown behind Safari’s rendering of MathML, but its problems have typically been poor horizontal spacing and a wandering baseline. Even if I wasn’t thrilled with its results, there always were results—not just an error message.

To reproduce the bug in a smaller example, I copied the page’s source code from around the troublesome equations, wrapped it in tags to create a complete HTML page, and uploaded it to my server to see how Mobile Safari would render this minimal test case. Here it is:

Test page rendered in Safari

(I’ve made it wider than the other screenshots to make the text a little easier to read.)

At first I was disappointed to see that the equations weren’t producing error messages, but that turned out to be a blessing in disguise. In both equations, the number 389.1067 is displayed as a link. That’s three digits, a period, and four digits. The light bulb went off in my head: Safari is treating this as a phone number. None of the other numbers on the page—the ones being displayed correctly—had that format.

“You dumbass,” I said to Safari. “Who puts phone numbers in equations?” But chastising software is about as successful as ignoring problems.

Initially I fixed the problem by splitting up the number in the MathML source. This turned, for example, the second equation from

<math xmlns='http://www.w3.org/1998/Math/MathML' display='block'>
  <mfrac>
    <mn>389.1067</mn>
    <mn>29.1067</mn>
  </mfrac>
  <mo>=</mo>
  <mn>13.3683</mn>
</math>

to

<math xmlns='http://www.w3.org/1998/Math/MathML' display='block'>
  <mfrac>
    <mrow><mn>389</mn><mn>.1067</mn></mrow>
    <mn>29.1067</mn>
  </mfrac>
  <mo>=</mo>
  <mn>13.3683</mn>
</math>

But that wasn’t a very satisfactory solution. With a bit of searching, I found that you can turn off Safari’s automatic formatting of phone numbers as links by including this meta tag in your page:

<meta name="format-detection" content="telephone=no">

Adding the tag eliminated the error message and got the original MathML rendered as expected in every browser I tried. For now, I’ve added this line just to the Antikythera page, but I think it should probably go into the header I use in every page of ANIAT.

As is often the case, I wrote this post as much for future me as for you. Unless I write them down, things like this disappear through the smoke rings of my mind. Thanks to tambourineman for the nudge to put seven-digit numbers far from the twisted reach of crazy Safari.

Update 17 Dec 2024 4:28 PM
Another helpful message on Mastodon, this one from jawbroken, pointing out that the error message I was seeing in the original version of the post was from MathJax, which is absolutely correct. Since I haven’t used MathJax in over a year, I’d forgotten that its messages had that red-on-yellow look.

So why am I getting MathJax error messages if I’m not using it anymore? Well, when I switched over, I was pretty sure that I’d converted all the old MathJax equations to MathML, but I wasn’t absolutely sure. So I left the MathJax configuration stuff in the blog’s boilerplate code just in case there were any stray unconverted equations hanging around. Until now, this hadn’t been a problem.

So in addition to adding the <meta> tag to turn off the autoformatting of things that look like phone numbers, I’ll also strip out all the MathJax configuration code and get rid of its icon over in the sidebar. I need to look up my notes on how to rebuild the entire blog; it’ll be interesting to see how long it takes on my new M4 MacBook Pro.


The Antikythera mechanism

A recent episode of the In Our Time podcast is about the Antikythera mechanism, which you’ve probably heard of. It’s a bronze device that dates back to the first century BCE and was found by divers on an ancient shipwreck off the Greek island of Antikythera in the early 1900s. It’s main purpose, as determined by slow study over the past hundred years, was to track the positions of the “planets,” which in its time were the Sun, Moon, Mercury, Venus, Mars, Jupiter, and Saturn.

The show is very good, covering both the mechanism itself and the development of what’s known about it. There’s also some fun speculation on who made it and who owned it. This post expands on a couple of numerical/astronomical/calendrical things mentioned by the guests.


At about the 32-minute mark, Mike Edmunds talks about a large wheel in the mechanism that has, he says, 233 teeth, equal to the number of lunar months in the Saros cycle, which is used to predict eclipses. I mention it here for two reasons:

First, Prof. Edmunds misspoke slightly. The Saros cycle is 223 lunar months, not 233. And it’s worth mentioning that what I’m calling a lunar month is also known as a synodic month and a lunation, depending on which reference you’re looking at. It’s the time between one new moon and the next,1 which is about 29½ days

Second, so you could see the spelling of Saros in case you wanted to do your own searching on the topic. If so, I recommend this article by Fred Espenak on NASA’s website. It includes two other month definitions, anomalistic and draconic.


Earlier in the show, at about the 14-minute mark, Jo Marchant talked about a particular gear train in the mechanism, in which

the first six gear wheels… convert the speed by a ratio of 254 over 19, which… harmonizes the motion of the Sun and the Moon.

I was out on a walk as I first listened to the episode, and I misheard this part. I thought she said 354 instead of 254. So my instinct was that the 19 came from the length, in years, of the Metonic cycle and that the 354 came from the number of days in 12 lunar months (12×29.5=354). I knew that the Metonic cycle was the period it took for a lunar calendar and a solar calendar to get back in sync,2 but I didn’t understand what that had to do with the number of days in 12 lunar months.

When I got home and listened to that chunk of the show again, I realized that I had misheard, but hearing it right led to another question. The Metonic cycle is 19 years or 235 lunar months—where does the 254 come from?

After some thinking, I realized that although there are 235 lunar months in a Metonic cycle, that’s not how many times the Moon orbits the Earth in 19 years. A new moon occurs when the Moon is directly between the Sun and Earth. Because the Earth has gone nearly 30° around the Sun in one lunar month, that means the Moon has gone nearly 390° around the Earth in that time. Over the course of a year, the Moon has made one more orbit of the Earth than you would think if you just divided the number of days in a year (365.2421881) by the number of days in a lunar month (29.53058891).

If you’re used to thinking in terms of sidereal time, or if you watched this Veritasium video on a screwed-up SAT question, you know that if there are 235 lunar months and 19 years in a Metonic cycle, the Moon must have orbited the Earth 235+19=254 times. Therefore, the number of Moon orbits and the number of Earth orbits must be in a ratio of 254:19.

If this still is still puzzling, a picture might help. Here are the Sun, Earth and Moon at two successive new moons, as viewed from “above” the solar system.

Sun-Earth-Moon movement over a lunar month

The angle that the Earth goes through in one lunar month is

29.53058891365.2421881360 &SmallCircle;=29.1067 &SmallCircle;

During that time the Moon goes around the Earth one full orbit plus that amount, or

360 &SmallCircle;+29.1067 &SmallCircle;=389.1067 &SmallCircle;

So the ratio of the Moon’s angular speed3 to the Earth’s is

389.106729.1067=13.3683

And over 19 years, the Moon goes through

19×13.3683=253.997&approx;254

orbits of the Earth. And this is where the 254:19 ratio comes from.

I can think of three objections to this calculation. Let’s go through them.

Elliptical orbits
Implicit in the calculation is that the orbits of the Earth and Moon are circular. This isn’t true, but it’s pretty close. The Earth’s orbital eccentricity is just 0.0167 and the Moon’s is 0.0549. More important, the angle calculations are averages; even though the Earth speeds up and slows down over the course of a year, its average angular movement is 29.1067° over an (average) lunar month.

Sidereal vs tropical year
You may have noticed that I used the length of the tropical year in the calculation. If I’m going to compare the motions of the Earth and Moon relative to the fixed stars, shouldn’t I be using the sidereal year of 365.25636 days? Strictly speaking, yes, but when the Antikythera mechanism was built the precession of the equinoxes had been known for only a century or so and may not have been known to the devices makers. It certainly wasn’t built into the Metonic cycle, which predated the discovery of precession by centuries. But even if I had used the sidereal year, the calculation would have been

29.53058891365.25636360 &SmallCircle;=29.1056 &SmallCircle; 360+29.105629.1056×19=254.006

which is still very close to 254. The precession adjustment is only about 1 part in 26,000.

Heliocentric motion
My sketch of the Sun-Earth-Moon system assumes a heliocentric solar system, something that wasn’t known to the Greeks of the first century BCE. In the podcast, Mike Edmunds says Greek philosophers of that time would have been open to the idea of heliocentric motion, but that’s a far cry from taking it as a given. But while the Greeks may not have known the reason for the Metonic cycle, they still knew it as an empirical fact, based on centuries of observations. Whatever caused the Moon and Sun to move across the sky as they did, they moved in a ratio of 254:19.


I’ve always liked blogging about calendrical things, but I don’t remember doing anything on the Metonic cycle before. If I had written faster, I could’ve published it on Friday the 13th. Too bad.


  1. Or one full moon and the next; the period is the same either way you look at it. 

  2. For example, there was a new moon a couple of weeks ago, on December 1, 2024. The next time there will be a new moon on December 1 will be in 2043. This is for Chicago, by the way; these new moons could be one day off in different parts of the world. The Metonic cycle was named after Meton of Athens, who lived in the fifth century BCE, and was well known in the Greek world. 

  3. Here I’m talking about the circular motion of their centers. This has nothing to do with rotation about their axes. 


More weight

Here’s a followup on my post about tracking and plotting my weight. The shortcuts we’ll cover were written a couple of weeks ago, but I thought weight would be a touchy subject during the week of Thanksgiving.

As you may recall, I’m using an app that (among other things) communicates with a smart scale to record my weight. But it doesn’t share that data with the Health app, so I pulled all the weights over the past 4–5 months out of the app, saved them to a CSV file, and wrote a short Python script to plot my weight over time. I also wrote a shortcut that I could run every morning to update the CSV file with that day’s weight.

A few days after posting, I realized that Shortcuts has actions that communicate with the Health app. So it should be easy to change the shortcut to both update the CSV file and send the data to the Health app. And it was easy; all I had to do was add one more step to the shortcut I’d already written. Here’s the new version:

StepActionComment
1 Weight Today Step 01 Get today’s date
2 Weight Today Step 02 Format the date as yyyy-mm-dd
3 Weight Today Step 03 Ask the user for today’s weight
4 Weight Today Step 04 Assemble the date,weight line
5 Weight Today Step 05 Append the line to the CSV file
6 Weight Today Step 06 Update the Health app with today’s weight

The only change is the addition of Step 6, which takes the weight that’s input in Step 3 and logs it to the Health app. Because the date argument of the Log Health Sample action defaults to today’s date, there’s no need to fill it in in Step 6.

That’s great going forward, but what about all the weights that were collected since July? For that, I had to do two things:

  1. Clear out all the weight data already saved in Health. Although my weight wasn’t added automatically to Health, I have been updating my weight (approximately) every month or so. That data had to go to make way for the correct data from the scale.
  2. Use the CSV file to enter all the weight data recorded there into Health.

To clear out the unwanted weight data, I opened Health, tapped the Weight category, and scrolled down to the bottom. This is where the Show All Data button is.

Buttons at the bottom of the Weight page

Tapping that button took me to a view of all my weight data in reverse chronological order. There’s an Edit button in the top right corner of the view; tapping it adds the red “No” buttons that allow you to delete any individual value. But what I did was tap the Delete All button in the top left corner. That got rid of everything.

Weight data in Health app

Now it’s time for a shortcut that enters the data from my CSV file. While I suspect there are prebuilt actions for reading and interpreting CSV files, I didn’t see any right away, so I decided to copy the data directly into the shortcut and use brute force to extract the dates and weights. Here’s the shortcut:

StepActionComment
1 Add Weights To Health Step 01 The weight data from the CSV file without the header row
2 Add Weights To Health Step 02 Split into lines
3 Add Weights To Health Step 03 Repeat with each line
4 Add Weights To Health Step 04 Split the line at the comma
5 Add Weights To Health Step 05 The first item is the date
6 Add Weights To Health Step 06 The second item is the weight
7 Add Weights To Health Step 07 Log the weight for the given day in the Health app
8 Add Weights To Health Step 08 End repeat loop

The first time I ran this, I noticed a problem in the data. There were two days I was out of town and didn’t weigh myself. These appeared in the CSV file like this:

2024-08-31,184.00
2024-09-01,184.79
2024-09-02,
2024-09-03,
2024-09-04,183.80
2024-09-05,184.99

When the blank values were logged into Health, they were interpreted as zeros, which made the plot of my weight in Health look pretty funny. So I deleted those two lines, went back and deleted all the weight data from Health, and ran the shortcut again. That put everything right.

I’ve kept this second shortcut around, even though I hope to never use it again. With luck, all I’ll have to do is run the Weight Today shortcut every time I weigh myself and both the CSV file and the Health app will stay up to date. Although I prefer the graph I made with Python and Matplotlib, the one in the Health app isn’t bad. And it’s generated automatically.

Weight plot from Health app


Thinking about AI

I’m still not sure how to think about AI. While some aspects of it seem useful, I’m not sure I care about them. The few times I’ve tried it out on topics of interest to me, using both ChatGPT and Perplexity it’s failed.

And there have also been failures on tests that I didn’t mean to run. Last week, during the Illinois-Northwestern football game, my sons and I were wondering whether a Northwestern receiver, Calvin Johnson, was related to the former Detroit Lions receiver of the same name (but who is probably better remembered for his nickname, Megatron). My older son pulled out his phone and Googled. The Gemini answer, which appeared above the links, said he was Megatron’s son, but the very first line of one of the top links said

He may not be related to Megatron, but Northwestern will welcome this Calvin Johnson to Evanston with open arms.

More disturbing than obvious outright errors like that is the possibility that using AI will affect our ability to judge its value. I’m thinking of something that came up in a recent episode of The Talk Show, the one with Joanna Stern. Starting about 53 minutes into the show, they start talking about they both asked ChatGPT to make an image of what it thinks their life looks like. Joanna tried it twice, and you can see the images by following links in the show notes. Prominent in both images were representations of scouting.

Why? Well, one of Joanna’s sons recently joined the Cub Scouts, and she’s asked ChatGPT about certain aspects of scouting. ChatGPT has taken these questions as an indication of her deep interest in scouting. In one image, there’s a big Boy Scouts poster on the wall; in the other, her computer screen has the BSA logo above her name and what look like a merit badge or two sitting on her desk. Both images have a boy with a neckerchief in the background.

Both Joanna and John seemed to think this is a reasonable (albeit funny) thing for ChatGPT to do. She asked about scouting, so she must be interested in it, right? And as I was listening to the show, I thought so, too.

But as I thought about it more, I realized this was backward. Instead of ChatGPT thinking like a person, we were thinking like it. The scouting imagery in Joanna’s pictures tells the viewer that she’s deeply into scouting, but the reason she asked questions is that she’s new to it. If she had asked her questions of any person—a scout leader or even another parent who’s kid had been in Scouts for a while—that person would have immediately known that Joanna was a newcomer, not an aficionado who’d have scouting posters on her walls, merit badges scattered across her desk, and the BSA icon on her Desktop wallpaper.

I find this insidious. Certainly, we were right about the reason ChatGPT put the scouting imagery in its pictures. But it was a dumb thing for ChatGPT to do, and none of us immediately called it out as such. We are, I fear, so deeply into computers1 that we accept the stupid things they do as normal and reasonable.

And because these photos aren’t “wrong”—unlike saying the Northwestern receiver is Megatron’s son—there’s no chance that ChatGPT will be improved in this regard. I’ll bet every programmer at OpenAI would look at Joanna’s photos and think “Oh yeah, that makes sense” just like we did.

Before I go, I want to mention that there are AI haters out there who strongly object to using words like “think” and “understand” when talking about AI bots. As someone who’s spent decades talking about how structures “want” to deflect in certain ways and “refuse” to move in other ways, this kind of anthropomorphism doesn’t bother me. It’s my own cybermorphism that worries me.


  1. Something ChatGPT didn’t pick up on with regard to John—there’s no computer in his picture