Four (or more) Macs

Yesterday morning, a new podcast episode popped up in my Castro inbox: a Relay B-Side called The Mac Draft.1 In it, Stephen Hackett, Christina Warren, Brian Sutorius and Ed Cormany did a four-round draft of significant or favorite Macintosh models. It’s a fun show, and you should give it a listen. (If you’re used to the draft shows on The Incomparable, fear not. This one’s only 48 minutes long.)

If you’ve been a Mac user for any length of time, you’ll probably think of which machines you would have drafted had you been on the show. I sure did, and that’s what this post is about. One restriction I’m going to impose on myself that the youngsters didn’t is that I will only draft Macs that I owned or was the primary user of at work. I like the personal touch.

Round One: SE/30


Image source: Wikipedia.

Yes, I know Ed drafted the SE/30 with his first round pick. I’m just going to assume that I went before him and sniped this pick. It’s my blog, and I’ll do what I want.

The SE/30 is the favorite of a lot of Mac users of a certain age. During the Mac’s 25th anniversary year, it was hailed as the greatest Mac ever by no less than Adam Engst, John Gruber, and John Siracusa. Introduced to the world at the beginning of 1989 and retired almost three years later, it was the apotheosis of the original Mac form factor.

I was teaching in 1989, and that fall one of my departmental colleagues got an SE/30. I was immediately filled with jealousy. When I changed jobs at the beginning of 1990, I persuaded my new employer to provide me with an SE/30, and the sour feeling of inadequacy washed away as I set it up at the corner of my desk.

That was the great thing about the SE/30. It was a serious workstation—the 68030 processor was a beast for its time—in a package that could fit almost anywhere. And when I was 30 years old, my eyes could handle the 9″, 512×342 pixel, black-and-white screen.

Round Two: 2010 13″ MacBook Air

MacBook Air

No need for a stock image of this one; it’s sitting on my lap right now. This is not the much-maligned original Air. It’s the second-generation model, the one they got right. Real ports, no flip-down door, and Flash storage instead of a 4200 rpm, iPod-class hard disk.

This machine was a revelation when I first got it. It booted up so fast. In fact, everything seemed extra quick, an indication that most of what I was doing was constrained more by I/O than by processing. And of course, it was so thin and light. Even after six years, I don’t really feel it’s a museum piece—it still gets the job done.

Although I drafted the SE/30 first, that was a tactical decision. This is my favorite Mac.

Round Three: 512K

Macintosh 512K

Image source: Wikipedia.

This was my first Mac. I bought it in grad school and wrote my Ph.D. thesis on it, using MacWrite, MacDraw, an ImageWriter, and Andy Hertzfeld’s amazing Switcher.

Although the formal name was 512K, based on its RAM, everyone called it the Fat Mac. Mine was configured with an external single-sided diskette drive to compliment the internal drive. That gave me a whopping 800 kB of storage for the system, the applications, and my files.

But the best thing about the Fat Mac was its RAM, something that didn’t become apparent until Switcher was released. Because applications had to be written to fit in the 128 kB of the original Mac, Switcher allowed you to fit the Finder plus two or three other applications into RAM and quickly flip back and forth between them. It wasn’t multitasking, but it was sure better than the usual launch/use/quit, launch/use/quit cycle. Given that I typeset by hand the equations for my thesis in MacDraw and then pasted them into MacWrite, Switcher was a godsend.

Round Four: Cheating

I have three Macs that I’d like to put into the fourth slot, and I don’t know which one to choose. So I’m just going to cheat by squeezing them all into one round. Again, it’s my blog.


Surprisingly, the SE/30 is the only overlap between my choices and the ones made by Stephen, Christina, Brian, and Ed. A good part of this is because my choices are biased toward the early days of the Mac—a lot of beige, as Stephen would say. But it’s also because 30+ years of design includes something for everyone.

  1. It has since appeared a second time as an episode of Simple Beep↩︎

Jake Arrieta and Python

Although Jake Arrieta still has good looking statistics for the season, my sense is that he’s been a mediocre pitcher since the All Star break. Am I right about this? Because it’s easy to get game-by-game statistics for almost any aspect of baseball, I figured it wouldn’t be hard to answer this question. More important, I could use this as an opportunity to practice my Python, Matplotlib, and Pandas skills.

Modern, stats-loving baseball fans can probably come up with a dozen ways to measure the quality of a pitcher, but I wasn’t interested in cutting-edge sabremetric research, so I stuck with pitching quality statistic of my youth, the earned run average. Remember, this is mostly an excuse to keep my Python skills sharp. Don’t write to tell me about your favorite pitching stat—I don’t care.

I started with a simple text file that looked like this:


Each line represents one game. The date is in month/day format, the earned runs are integers, and the innings pitched are in a hybrid decimal/ternary format common to baseball, with the full innings before the period and the partial innings after it. The full innings are regular decimal numbers, but the partials represent thirds of an inning. The number after the period can take on only the values 0, 1, or 2.

Because I knew Pandas would look at the IP values and interpret them as regular decimal numbers, I decided to massage the input file first. Also, I figured it wouldn’t hurt to add the year to the game dates. After a couple of find-and-replaces in BBEdit, the file looked like this:


Now there are separate fields for the full innnings and partial innings pitched. Time to fire up Jupyter and commence to analyzin’.

import pandas as pd
from functools import partial
import matplotlib.pyplot as plt
%matplotlib inline
plt.rcParams['figure.figsize'] = (12,9)

This is mostly standard preamble stuff. The odd ones are thercParams call, which makes the inline graphs bigger than the tiny Jupyter default, and the functools import, which will help us create ERAs over small portions of the season.

Next, we read in the data, tell Pandas how to interpret the dates, and create an innings pitched field in standard decimal form:

df = pd.read_csv('arrieta.txt')
df['Date'] = pd.to_datetime(df.Date, format='%m/%d/%Y')
df['IP'] = df.FIP + df.PIP/3

Now we can calclulate Jake’s ERA for each game.

df['GERA'] = df.ER/df.IP*9

To get his season ERA as the season develops, we need the cumulative numbers of innings pitched and earned runs given up. That turns out to be easy to do with the Panda’s cumsum method.

df['CIP'] = df.IP.cumsum()
df['CER'] = df.ER.cumsum()
df['ERA'] = df.CER/df.CIP*9

Let’s see how his ERA has developed:

plt.plot_date(df.Date, df.ERA, '-k', lw=2)

Arrieta ERA through season

The rise in May, though steep, doesn’t indicate poor pitching. Arrieta just started the season out so well that even very good pitching looks bad in comparison. It’s the jump in late June and early July that looks really bad. And now that I think of it, the Cubs did have a terrible three-week stretch just before the All Star break. Arrieta’s performance was part of that, so his slide started earlier than I was thinking.

But even after the big jump, there’s been a slow climb. So even though the Cubs have played excellent ball since mid-July, Arrieta hasn’t. To get a better handle on how poorly he’s been pitching, we could plot the game-by-game ERAs, but that’s likely to be too jumpy to see any patterns. A way to smooth that out is to calculate moving averages.

But what’s the appropriate number of games to average over? Two is certainly too few, but three might work. Or maybe four. I decided to try both three and four. To do this, I defined a function that operates on a row of the DataFrame to create a running average of ERA over the last n games:

def rera(games, row):
    if < games:
        ip = df.IP[].sum()
        er = df.ER[].sum()
        ip = df.IP[].sum()
        er = df.ER[].sum()
    return er/ip*9

The if part handles the early portion of the season when there aren’t yet n names to average over. Looking at the code now, I realize this could have been simplified by eliminating the if/else and just using


as the lower bound of the slice. Oh, well. I’ll leave my crude code here as a reminder to think more clearly next time.

With this general function defined, we can use the partial function imported from functools to quickly define running average functions for three and four games and add those fields to the DataFrame.

era4 = partial(rera, 4)
era3 = partial(rera,3)
df['ERA4'] = df.apply(era4, axis=1)
df['ERA3'] = df.apply(era3, axis=1)

Now we can plot everything:

plt.plot_date(df.Date, df.ERA3, '-b', lw=2)
plt.plot_date(df.Date, df.ERA4, '-r', lw=2)
plt.plot_date(df.Date, df.GERA, '.k', ms=10)
plt.plot_date(df.Date, df.ERA, '--k', lw=2)

Arrieta various ERAs

As you can see, I didn’t bother to make this look nice. I just wanted to dump it all out and take a look at it. I don’t see much practical difference between the three-game average (blue) and the four-game average (red). Arrieta did have a good stretch there in late July and early August (which I hadn’t noticed), but he’s not been pitching well since then. It’s not unlike his early years with Baltimore. I’ll be curious to see where he’s put in the playoff rotation.

As is usually the case with my baseball posts, I’ve learned more about programming tools than I have about the game. I’ve used partial many times in the past, and I always feel like a real wizard when I do. But I’ve never used cumsum before, and I’m really impressed with it. Not only does it perform a useful function, it’s implemented in a way that couldn’t be easier to use for common cases like the ones here. I hope I don’t forget it.

Update Sep 24, 2016 9:33 PM
Of course I take full credit for Arrieta’s performance the day after this was posted. Jake obviously reads this blog, especially for the Python-related posts, and realized he needed to step up his game after seeing the clear evidence of how he’s gone downhill recently.

Fractionally improved

There’s a new version of PCalc in the App Store, and it has a great new feature for those of us who have to work with lengths measured in inches and fractions of an inch. It’s a display mode that allows all your calculations to be kept in fractional notation rather than converted to decimal form. This is remarkably generous for a developer, James Thomson, who lives in Europe, where you can, I believe, be thrown in jail for failing to worship the Decimal God of Metric.

PCalc has for some time been able to accept fractional input. If, for example, you wanted to enter 1⅝, you can tap out the sequence

1 . 5 . 8

And the number you want will appear in the display (assuming you have the Quick Fraction Entry preference set in Advanced Settings).

Quick Fraction Entry

Up until now, that number would change from




when you tapped any operation key or (if you work in RPN, as all right-thinking people do) the Enter key.

But with PCalc 3.6, you can set the display mode to Fraction, either in the Settings

Fraction Display Setting

or by tapping and holding on the display area.

Action Buttons

What’s great about this is that it allows you to get fractional answers when that’s the natural way to present the results. For example, we can add 1⅝″ and ¾″1

Fractional Input

to get 2⅜″.

Fractional Answer

Sure, it’s easy to see 2.375 and think 2⅜, but even us old hands at decimal-fraction conversion hesitate when dealing with 16ths and 32nds.

I’m told PCalc 3.6 has some cool features that work with iOS 10. I wouldn’t know, as I haven’t tried out Apple’s public beta and don’t intend to install the released version of iOS 10 until the initial excitement—and the initial bugs—have passed by. What I do know is that PCalc 3.6 is an excellent update even on my horribly outdated iPhone 6S running iOS 9.

  1. To enter a pure fraction, tap the decimal point key twice between the numerator and the denominator, e.g., 3 . . 4

S Club 7?

As a rule, I don’t buy a new phone every year. I like my iPhones, but a new phone every other year is good enough for me. I’ve come to prefer the S versions. With an S, you don’t get the newest enclosure design, but you do get the refinements that come with a year of experience, and you typically get a serious improvement to the internals. But it looks like that pattern will be broken with the 7.

I switched to the S Club with the 5S. I had a 5 (actually, I had three 5s—two of them were replaced because of dust between the camera lens and sensor), but I went ahead and bought a 5S because my son’s 4 was on its last legs and needed to be replaced. He got my 5 as a hand-me-down.

The 5S, as you may recall, was a big jump up from the 5 despite having essentially the same case geometry and overall look. The processor went from 32 bits to 64, the home button got Touch ID, the camera got burst mode, and the case became more scratch-resistant. Also, I never had any problems with dust under the 5S’s camera lens.

I skipped the 6 and waited for the 6S,1 which meant I got the way way faster Touch ID, the stronger frame, twice the RAM, improved LTE networking, and the usual faster processor and better camera. S Club wins again.

But the 7 is the third version of this enclosure design, and it seems extremely unlikely we’ll see an S version of it.2 More important, next year is the 10th anniversary of the original iPhone, and Apple will certainly mark the occasion with a major change in case design. Sadly, there will be no S Club 7.

What will I do? Get the 10th Anniversary iPhone? Wait around another year for what will certainly be a distinctly better version of that design? I suspect I’ll be unable to resist whatever comes out in 2017, and I’ll have to tear up my S Club membership card.

  1. By the way, I don’t care whether Apple capitalizes the S. I do because otherwise it looks like a plural. 

  2. Were it not for the Nazi connotations, the 7 would be more properly named the 6SS.