# Siri and numbers

Several years ago, I wrote a post about using Siri to dictate measurements as I take them. I still do that, and it still works very well because Siri is fast and accurate at transcribing numbers. By using Siri as a sort of secretary, I don’t have to switch between my measuring tools and a notebook, and I don’t have to worry about mistyping a number on my phone’s keyboard. Over the past year, I’ve learned a new Siri trick with numbers: addition.

In my job, I often need to go through a set of drawings of a building or a machine, determine how many times a certain feature or part is used on each drawing, and then add them up. This obviously isn’t hard work, but it’s dull, and it’s easy to make mistakes when work is dull. But Siri doesn’t care if the work is dull, and because of the way it answers questions, it provides an automatic error-checking system.

Let’s say I have a list of numbers to add—all the Grade 5 bolts used in a machine housing, for example. I say, “Hey, Siri, what’s seven plus twelve plus fourteen plus four plus…” and wait for the answer. Siri responds, “Seven plus twelve plus fourteen plus four plus… is 73.” I not only get the result without a math error, I also get an echo of all the individual numbers, so I can make sure that Siri understood them all1 and that I didn’t skip or misread any of them. It’s faster and more accurate than I can do it with a calculator or spreadsheet.

There are limits. I’ve found that Siri tunes out and just won’t answer if the list of numbers is too long. Siri can handle lists of over fifteen numbers, but I generally don’t try more than about ten at a time. It’s easy enough to break a long list into sublists that Siri can then add later. Also, dictating out a long list of “A plus B plus C plus D plus…” is tiring and prone to error on my part.

(I do feel a twinge of embarrassment at using voice recognition and network access just to add a column of figures. That’s a lot of computing resources to throw at a such an elementary problem. But it’s a better way of adding.)

As you might expect, Siri can be weirdly persnickety in how you phrase the request. For example, “Hey, Siri, add one and two and three” will get the response “One plus two is three.” Not helpful. But if you ask, “Hey, Siri, what is the sum of one and two and three,” it will tell you what you want.2

I came across this way of getting sums in the past year because of the pandemic. I’ve been working at home, where there’s a HomePod near my desk, and one day it dawned on me that if it could understand my telling it to play “Sketches of Spain,” it could handle simple addition. I doubt I would have ever learned this at the office because

1. I don’t use Siri on my Mac.
2. If I pick up my phone to do a calculation, I’m going to open PCalc out of habit.

It was only because I’m used to talking to my HomePod that I thought of doing the sums this way. As things head back to normal and I spend more time at the office, I’ll try to take this lesson with me and do more by talking to my phone and watch.

1. I’ve sometimes garbled my words badly when doing this, but I’ve never caught Siri in a transcription error. I think the word “plus” makes the context clear, and every number is interpreted as such.

2. I prefer saying “and” repeatedly to saying “plus” repeatedly, but I usually forget the proper preamble (I just had to test it to write this paragraph) so I typically go with the “plus” formulation.

# Airtime

I suspect a lot of us who bought M1 MacBook Airs are thinking about the next generation low-end MacBooks (whether Apple calls them Airs or not) and wondering if maybe we should have waited a year for a step up in Apple Silicon power. That’s certainly the common regret in computer buying—that if we’d just held off a little longer, we’d have gotten something much better. But recently I’ve been thinking that regret may work the other way this time.

These are the things I’ve been putting together:

• The current MacBook Air is an M1 system put into a shell made for larger and more power-hungry Intel guts.
• As a result, I get actual all-day battery life from my Air. Not Apple’s idea of all day, but a full 16 hours with no concern about having to plug in. To me, this has been even more pleasing than the speed increase.
• Apple’s tendency to go thinner and lighter—along with it’s traditional definition of “all day”—suggests that the next generation of low-end MacBooks will have less battery than today’s Air. Shaving three-quarters of a pound or more will feel good in the backpack, but when it’s late in the day, you’ll have to rummage around in that backpack for the charger.

Undoubtedly, there are people who will happily trade five of six hours of battery life for a significantly lighter machine. And there may come a time when I’ll be one of them. But not now. Because of Apple’s weird interim Air design, I may have stumbled into the ideal computer for me.

# What’s the diff?

This morning’s post by John D. Cook brought up an interesting problem: what’s a good way to check for differences between files when the files consist of just a few (or maybe just one) very long lines?

The problem is that diff, the standard Unix tool for finding differences, tells you which lines are different. This is great for source code files, which are written by human beings and in which the lines tend to be short, but not so much for machine-generated files like JSON, XML, and some HTML files, in which line breaks may be few and far between.

Cook’s solution for comparing long-lined files is to pass them through fold before sending them to diff:

diff <(fold -s -w 20 temp1.txt) <(fold -s -w 20 temp2.txt)


The -s option tells fold to break at space characters instead of in the middle of a word. The -w 20 option tells it to make the new lines no more than 20 characters long. Breaking the text into lines of only 20 characters is overkill, but it certainly is easy to see differences between lines when you have only 20 characters to scan through.

The <() thing is a bit of clever shell scripting known as process substitution. It’s used instead of piping when you have more than one input that needs to be fed to a command.

I was unfamiliar with fold until today. Whenever I’ve needed to reformat a text file to a given line length, I’ve used fmt. What I like about fmt is that it defaults to breaking lines at spaces—no need for the equivalent of the -s option. So I’d do

diff <(fmt temp1.txt) <(fmt temp2.txt)


if I were OK with fmt’s default line length of 75 characters, or

diff <(fmt -20 temp1.txt) <(fmt -20 temp2.txt)


if I wanted to use Cook’s extremely short lines.

But I’d be even more likely to open both files in BBEdit and use its command. That would give me this nice two-pane output:

In this example, there’s only one line, but it’s broken into easily digestible pieces by BBEdit’s soft wrapping, and the exact spot at which the difference occurs is highlighted by the darker purple background.1

There is a diffing app called Kaleidoscope that I’ve heard good things about, but I’ve never felt hampered by BBEdit.

1. In his example text, Cook punned by changing Melville’s “hypos” to “typoes.” Not to be outpunned, I changed it to “typees.”

# The two Johnnies

I was out running errands in the middle of the day, so I only saw the last 15 minutes or so of today’s Apple Event. But it didn’t take long to catch up.

Given the pre-event rumors and the graphic in the invitation, I don’t suppose it surprised anyone that colors came back to the iMac. I admit, though, that I was surprised at how bold the colors are, at least on the back sides.

For over a year, ever since Jony Ive said good-bye, I’ve been waiting for color to return to the iMac. It seemed to me that the spare aluminum iMac, whose fundamental design has been unchanged since 2012, was Jony’s ideal iMac. Oh, I’m sure he would’ve gotten rid of the bulge in the back if it weren’t for the thickness of spinning disks and the need to cool Intel’s chips, but I think he considered the bare aluminum and glass look to be pure and honest. It’s the truest evocation of the materials used to make the device and what he’d been working toward for years. That’s why the 2012 design persisted for so long. Why mess with perfection? And who was left at Apple to tell Jony that it wasn’t perfect?

But now that it’s been a decent interval since he left, Apple’s industrial design can move on. I expect we’ll see colors leak back into several colorless product lines. I’m not sure what we’ll see in the upcoming large iMacs and more powerful MacBook Pros; Apple may still be reluctant to add anything more than anemic pastels to its “pro” line. But the MacBook Air is an obvious target. The first M1 Airs, like the one I’m typing on right now, kept the old look because it was faster and cheaper to do it that way, but I’d be very surprised if the next generation of Airs weren’t at least as colorful as what we saw in today’s small iMacs.

The other big change in the look of today’s iMacs is due primarily to someone who isn’t on the industrial design team: Johny Srouji. The iPad-like look of the new iMac is possible because of the iPad-like chip that drives it. And the size and shape of every Mac that Apple makes from now on is going to be based on parameters set by Johny’s chips. Small, efficient, and cool, those chips are going to set the boundaries within which Evans Hankey and her team will work.

I’m sure Jony is happy with his decision to leave Apple after so many years. But I suspect he sometimes looks down from his pure white realm and thinks about what he could do with Macs if he had Johny’s chips to work with.