# Defaults delete

Five years ago, I started using some defaults write customizations of Safari (which was on Version 6 at the time) that bumped up the default font sizes and made most websites easier for me to read. Today I deleted those customizations because I learned of a preference setting that made them superfluous.

Safari 6 took away the Appearance preference pane, which I had been using to increase its default font size from 16 to 18.

This was one of those infuriating things Apple often does: sacrificing user freedom on the altar of simplicity. Luckily, the settings in the deleted pane were still accessible via the command line. These four lines,

defaults write com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2DefaultFontSize 18
defaults write com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2StandardFontFamily Georgia
defaults write com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2FixedFontFamily 'DejaVu Sans Mono'
defaults write com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2DefaultFixedFontSize 15


brought me back to where I’d been. Surprisingly, those additions to the com.apple.Safari.plist preference have continued to work through all the updates in the intervening five years.

Generally speaking, these changes to the defaults have worked well, but there are some stupidly designed web sites that become unusable if the default font size is anything other than 16. On these sites—whose designers, come the revolution, will be the first up against the wall—my changes cause buttons to get covered up by other page elements and become unclickable. I’d like to simply avoid these sites, but one of them happens to be the new online portal to my company’s bank. It’s a site I really need to use.

So today I took the plunge and deleted the troublesome preferences with

defaults delete com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2DefaultFontSize
defaults delete com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2StandardFontFamily
defaults delete com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2FixedFontFamily
defaults delete com.apple.Safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2DefaultFixedFontSize


and the bank site adjusted itself to make the buttons clickable. The tradeoff would be text that’s harder to read, except…

At some point, Safari added the incredibly useful Page Zoom setting to the Advanced preference pane.

I remember OmniWeb had this setting back in the day, and I was glad to see it in Safari. Now I have sites that work right and have text large enough for me to read.

But it did raise the question: how long has this setting been in Safari without me knowing about it?

I’ve run into this problem before. An application I’ve been using for years releases an update with a few big new features that get a lot of fanfare and several smaller ones tucked away in odd corners. Because I think I know the product very well—after all, I’ve been using it for years—I don’t look in those odd corners and miss out on capabilities that would really help me. Sometimes, as with Safari’s Page Zoom, I eventually find them on my own. Sometimes I complain about a “missing” feature and get gently corrected on Twitter.

# Experimental mechanics

A few days ago I got a call from a friend with an interesting problem. He’s investigating the failure of a long hollow steel rod, a rod that was said to have undergone helical buckling, and he wanted some help understanding the stresses and strains the rod had been subjected to when it buckled. I’ve done a lot of buckling analysis but never of helical buckling, so I told him I’d have to do a little studying and get back to him.

Helical buckling is a phenomenon that’s well known in the oil drilling and related industries but almost unheard of elsewhere. It occurs when a long rod that’s loosely encased in a larger diameter tube is compressed beyond its stability limit. If it weren’t for the tube that surrounds it, the rod would simply bow out to the side like Charlie Chaplin’s cane.

But the surrounding tube constrains the buckling rod, and if you keep compressing it, it will eventually wind itself into a helix in contact with the inner wall of the outer tube. The equations of a helix are fairly simple, so it’s easy to describe the midline of the buckled rod, but I was interested in whether the cross-section of the rod would rotate about its midline as it buckled, something the equations of the midline don’t tell you. It seemed from what I’d read that the cross-section shouldn’t rotate, but I wanted to see it for myself—not in a drawing, but in the flesh.

Not having hundreds of feet of steel tubing at my disposal, I started looking around the office for things I could put together. Here’s what I came up with:

The rod is two plastic stick eraser refills glued together end-to-end. The enclosing tube is a graduated cylinder. We had lots of PVC and metal tubes around the office, but the graduated cylinder was the obvious choice1 because it allowed me to see the buckled rod inside it. The black thing on top of the rod is the cap from a vial that fits fairly nicely in the cylinder and holds the top of the rod. Finally, the white plug at the top of the cylinder is a plastic block eraser that I trimmed down to fit snugly in the cylinder. When I pushed the block eraser down into the cylinder, it buckled the rod into a helix and held it there.

Can you see that the rod is helical? If it looks more like a plane sinusoid to you, this video may help.

Except at the very bottom, the rod is up against the inside of the glass cylinder.

Looking back at the photo, you can see that the writing along the rod is always facing towards us. Therefore, the cross-section doesn’t rotate during the buckling. This is what I’d read, but now I could visualize it, and I felt more comfortable using the equations for stress and strain.

Although I spent a lot of time in school learning analytical techniques, most of my professors (the ones whose lessons stuck with me) emphasized the importance of physical understanding, how to “think like the structure” before doing any calculations. And when the structure is too smart for me, I try to make little models like this so I can learn how it thinks.

1. I was going to say “the clear choice,” but I didn’t want to make such a transparent pun.

# Paperless and clueless

Most of my company’s clients still pay us by check. This works out well, because most accounting software prints out additional information—most importantly, our invoice number—on either the check or the stub that comes with it. That helps us figure out which invoice(s) the check should be applied to in our accounting software.

Image from ANS Systems

But in our brave new paperless world, more clients are directly depositing their payments in our bank account. This is convenient for them, I suppose, but it usually isn’t for us. What generally happens is a deposit gets made in our account without all that helpful extra information. Typically, we see the payer, the amount, and the date and that’s it. Sometimes that’s enough to work out which invoice got paid, but not always.

Today we got notice of a direct deposit payment of $16,604.10 from a client who had eight outstanding invoices spread out over several projects. No individual invoice was for that amount, nor was the total of all eight, so I had to figure out which combination of invoices had been paid.1 Turns out™ this was pretty easy. Python’s itertools library has a combinations function that generates all the combinations of a given length from a given list. For example, python: for i in itertools.combinations([1, 2, 3, 4, 5], 3): print i  prints (1, 2, 3) (1, 2, 4) (1, 2, 5) (1, 3, 4) (1, 3, 5) (1, 4, 5) (2, 3, 4) (2, 3, 5) (2, 4, 5) (3, 4, 5)  All I needed to do was make a list of the eight outstanding invoice amounts, generate all the combinations of length 2 through 7 (remember, I knew the payment didn’t match the total of all eight), and print out the one(s) that added up to$16,604.10. The only thing that worried me was using an equality check on a sum of floating point numbers. I could have used the decimal module, but I figured it was easier to just use integers and express all the values in cents.

Here’s the code:

python:
1:  #!/usr/bin/env python
2:
3:  from itertools import combinations
4:
5:  payment = 1660410
6:  invoices = [46500, 105250, 539439, 827471, 223750, 23250, 773212, 15500]
7:
8:  for n in range(2, len(invoices)):
9:    print "Testing combinations of {} invoices...".format(n)
10:    for c in combinations(invoices, n):
11:      if sum(c) == payment:
12:        print c


The output was

Testing combinations of 2 invoices...
Testing combinations of 3 invoices...
Testing combinations of 4 invoices...
Testing combinations of 5 invoices...
(46500, 539439, 827471, 223750, 23250)
Testing combinations of 6 invoices...
Testing combinations of 7 invoices...


which meant the invoices that had been paid were the ones for $465.00,$5,394.39, $8,274.71,$2,237.50, and $232.50. I suppose I could’ve figured this out without Python. After all, I knew immediately that two of the paid invoices had to be$5,394.39 and $8,274.71 because the total ended with 10 cents. Similarly, I knew$7,732.12 couldn’t be part of the total. That would’ve left me with the simpler problem of finding some combination of the five remaining invoices that added to \$2,935.00.

But using itertools was more fun, and it gave me a general tool I’ll be able to use in the future.

1. Couldn’t I just call the client and ask? No, because “the client” was really several branches of a corporate parent. Our project contacts don’t work together. They submit our invoices up the corporate ladder, but they have no idea when they get approved or paid. And working my way through an accounts payable department would’ve taken longer than writing this little script.

# Math without LaTeX

The mathematical typesetting rules I mentioned in my last post aren’t the dictates of Don Knuth. Although TeX’s aesthetic dominates technical publishing today—we tend to see it as correct because we’ve seen so much of it—the rules codified (literally) in TeX are based on ideas developed over decades. The goal of all mathematical typesetting is to present the equations with clarity and grace, the same goals as the math itself. Knuth studied the state of the art so he could make that same clarity and grace available to everyone.

I have a small collection of old structural mechanics textbooks. Yes, some of them are the texts I used in college, but most are items I’ve picked up in used bookstores over the years. The equations in some of them are pretty poorly laid out, but those from the top technical publishers have a consistent and elegant house style that persists across their catalogs. While Knuth certainly wasn’t looking at any of these books when creating TeX, he was looking at other works from these publishers, and it shows.

Here’s a page from Stephen Timoshenko’s two-volume Strength of Materials from Van Nostrand. My copy is the third edition from 1955 (the first edition came out in 1930).

McGraw-Hill was something of a step up from Van Nostrand. Here’s a page from Timoshenko and Woinowski-Kreiger’s Theory of Plates and Shells, the second edition from 1959 (based on a first edition from 1940).

To my eye, McGraw-Hill’s thinner integral signs are nicer, although I do prefer Van Norstrand’s placement of the limits. One of my favorite things about this page is the fearless use of huge summation signs. Some publishers stick with smaller summation signs, even when what’s being summed is tall. The large signs give you a better sense of the structure of the equation.

My favorite technical publisher is Wiley. Here’s a page from Henry Langhaar’s 1962 Energy Methods in Applied Mechanics.

There is a rhythm to those last four equations—the basis of the finite element stiffness matrix for beam bending—that’s reflected in the rhythm of their layout.

(And look at that figure of the bent beam. So much information packed into a small space, but with every force, moment, dimension, and angle depicted with absolute clarity. The differences in line thickness, arrowhead style,1 and dash spacing all contribute to your understanding of the equations below.)

Here’s a quick comparison of the Wiley and LaTeX renderings of the same equation:

Font differences aside, they’re pretty darn close. I prefer how Wiley puts the minus sign a little closer to the K, and I’ve always thought TeX’s sub- and superscripts were a bit too big. On the other hand, Wiley went overboard on kerning the superscript in the denominator of the last term.

FYI, the images in this post were, for the first time in the history of this blog, done entirely in iOS. The page images were shot, straightened, and cropped in Scanner Pro, the LaTeX formula was rendered in Pages, and the equation comparison was assembled in Pixelmator.