Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 12: Analogies in /Image and Logic/

Throughout the discussion of Galison’s /Image and Logic/, I’ve been alluding to reasoning by analogy. For example, the bubble chamber builders thought about the bubble chamber through analogies to the cloud chamber.

In this episode, I’ll look at two examples of analogy. In the first, I’ll start with an analogy that physicists mostly rejected, to their benefit, and an analogy that we accepted, to our sorrow.

Next I’ll give a quick peek at a paper that suggests that Galison made a key error in his analogy of the trading zone. That will serve as a teaser for post-Galison episodes. Enough of particle physics already!

Much of the theory of particle physics was built on differential equations. Differential equations relate the rate of change of output variables to the rate of change of input variables. Sometimes differential equations have so-called “closed-form solutions”, which are, roughly, equivalent equations that don’t involve rates of change. Other times, they have no closed-form solutions, but there are still – let’s call them partial solutions – that calculate some things about your particular problem, possibly the very things you need to know.

In the old days, if that didn’t suffice, you were kind of stuck. However, computers were coming on the scene at the end of WWII, which raised another possibility: you could convert the differential equation into a *difference equation*. Suppose you have a differential equation about change over time. A corresponding difference equation would relate an output value at time `t` to its value at time `t-1`. So what you can do is start at time 0 and keep feeding the output of one cycle into the input of the next. All it takes is the ENIAC computer, a bunch of punch cards to use as intermediate storage, and a lot of time. (An early proof of concept ran for six weeks.)

That approach might still be intractable. John von Neumann had a problem that involved the collective behavior of 6 times 10 to the 23d neutrons. However, he argued that simulating the behavior of 100 neutrons would be computationally tractable with the computers of the time, and would have results “close enough” to the true behavior.

Another step was taken by Stanislaw Ulam, who later wrote:

“The first thoughts and attempts I made to practice [what came to be called the Monte Carlo Method] were suggested by a question which occurred to me in 1946 as I was convalescing from an illness and playing solitaires. The question was what are the chances that a Canfield solitaire laid out with 52 cards will come out successfully? After spending a lot of time trying to estimate them by pure combinatorial calculations, I wondered whether a more practical method than "abstract thinking" might not be to lay it out say one hundred times and simply observe and count the number of successful plays. This was already possible to envisage with the beginning of the new era of fast computers, and I immediately thought of problems of neutron diffusion and other questions of mathematical physics, and more generally how to change processes described by certain differential equations into an equivalent form interpretable as a succession of random operations. Later [in 1946], I described the idea to John von Neumann, and we began to plan actual calculations.”

As Monte Carlo methods evolved, they began to be applied to problems without as much reference to underlying differential equations. Ulam even applied it to boolean logic to estimate a probability that a proposition was true.

A question that kept coming up in letters and conference Q&A sessions was: what were these people *doing*? Was it theory? Not really. People like Dirac and Einstein believed (to differing degrees) that theory was about representing the truth of the world in differential equations. It was those equations that answered the key question: “*why* does nature behave in this way?” Theory is not a thing you run again (with a different random seed) and potentially get different results. On the other hand, theorists do spend their time working with symbols on a blackboard, and that seems a lot like manipulating variables in a computer. They are at the same kind of distance from the phenomenon being studied.

And Monte Carlo couldn’t be experiment, could it? Because, well, you weren’t pushing at nature to see how it pushed back: you were running a computer program. It’s true it had some of the aspects of experiment: a construction error might cause nonsensical results that had to be debugged. Results could only be measured to a certain precision: you got answers that were plus or minus some uncertainty. And there was a need to check that results stayed stable when you varied things that supposedly didn’t matter.

To make things more confusing, central to the technique was this new thing: random numbers. Except they weren’t random numbers. For a given seed and algorithm, all the numbers were the opposite of random: completely predetermined. As Von Neumann said, “Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin.” This made some people uncomfortable on both a conceptual and practical level: if the problem being addressed had properties correlated with the number-generating algorithm, you could get bogus results. That wasn’t an idle worry. It turned out that IBM’s OS/360 random number generator was lousy, which led to some embarrassingly wrong conclusions.

Here’s a quote from two applied mathematicians: “We cannot emphasize too strongly that the random element of Monte Carlo work is a nuisance and a necessary evil, to be controlled, restricted, excised, and annihilated whenever circumstances allow.” (Weirdly, they said that “random element” was just the sort of thing you’d expect from *those people*: you know, pure mathematicians with their frivolous pursuits. I would have expected it the other way around.)

Meanwhile some Monte Carlo-ists fired back that it was actually *differential* equations were the approximation to reality. In real reality, individual neutrons really do move through space, encounter atoms, either bounce off them or split them, with some probability of each. Reality is fundamentally stochastic, fundamentally described by a probability distribution. To these people, differential equations had only come to matter because, pre-computer, people didn’t have the computational resources to do simulation.

So, lots of fights. However, those fights seem to have gotten resolved relatively quickly, because you can’t argue with results. Monte Carlo methods were justified by being crucial to the explosion of the first hydrogen bomb. At the time, that was the most complicated scientific problem ever. Unlike the fission bombs of World War II, it required detailed understanding of, say, how shock waves propagated through structures that were being vaporized by enormous heat. And experiments were of little help. In 1942, Enrico Fermi could pile up uranium bricks at the University of Chicago to (relatively) safely produce the first nuclear reactor. No equivalent was possible when dealing with temperatures like those at the heart of the sun.

Thereafter, simulation techniques became their own thing, not having to be classified as either experiment or theory. They had their own journals, their own career paths, and so on. And Monte Carlo spanned fields. Very quickly, it was of interest to chemists, engineers, quantitative biologists, and so on. It could stand on its own because it was relevant to *so much*.

Here’s what I want to say.

The claim that quote “software engineering” is a kind of engineering is as valid as the claim that “Monte Carlo approximations” are a kind of experiment. That is: not particularly valid, and not particularly helpful. I’ll say what I mean by “not helpful” in a bit, but first I want to be a little more specific about the word “analogy”.

People have been arguing about what analogies are for, for at least 2500 years, and there are lots of different opinions about how they work in the brain. I’m going to go with a no-doubt-crude version of what’s called the structure mapping theory. In it, you have a *source* that you understand well enough and a *target* you want to understand better. Both source and target can be represented as graphs, where nodes are things or nouns and edges represent relations. When reasoning using an analogy, you try to construct a *mapping* from the source to the target. Imagine that meaning you can draw a dotted line between, say, a source node and a target node because they’re in some sense the same. And you can do the same for relations. The better the analogy, the more similar the shapes of the graphs; that is, the more dotted lines you can draw between them. You use the analogy to reason by taking a node or relation in the source and asking if such a thing could exist in the target and what the similarity might be.

Let’s take an example that I think I got from a book called /The Way We Think/, by Fauconnier and Turner. It’s the insult “That surgeon is a butcher.”

Here are some mappings: both surgeons and butchers are humans, both get paid, both typically wear white coats, both wield sharp objects, both use those objects to cut meat.

But there are noteworthy characteristics of a butcher that seem to map onto a surgeon more awkwardly:

* Butchers don’t put the meat they cut back together again.
* Butchers don’t operate with a lot of artfulness or precision.
* Butchers do not save lives.
* Butchers are generally low-status (at least compared to the average surgeon).

If you *do* map those characteristics across to a particular surgeon, you get a conflict with what you’d hope to be true of surgeons. That’s why the analogy is an insult: it says the surgeon is a *bad* surgeon, and it suggests some reasons why.

Saying “simulations are experiments” suggests you get useful answers when asking “what properties of experiments apply to simulations, and how?” You certainly get *some* useful answers. Like I mentioned above, experimenters want their results to be stable when supposedly-irrelevant factors change, and so do simulators.

But, generally speaking, Monte Carlo simulations don’t map to experiments particularly well, and what insights there are to be had, have already been found. Even if the correspondence was credible in the beginning, Monte Carlo has developed its own divergent tradition (tradition in the sense of episode 11) with lots of ideas that have nothing to do with physical experiments. When solving simulation problems, looking to experimentation is probably not a great bet.

Let’s move to software. The analogy of software creation to engineering, and the coining of the phrase “software engineering”, took place in the 1960s or possibly as early as the 1950s. The analogy really took root because of the 1968 NATO Conference on Software Engineering (which might also have been the origin of the analogy between building architecture and software architecture).

I recently speed-read the proceedings, and I can’t say the attendees had any clear idea of how creating programs might be akin to engineering. It was mostly aspirational: hey, those guys over there seem to have their act together, and we don’t, so we should be like them. I didn’t read the working papers, but the 133 summary pages didn’t have any discussion of the form “in engineering field X, here is how a project would be managed and developed, and I will now describe how activities in a software project might map onto activities in that engineering project”.

As I write this script, the NATO conference was halfway done on this day 54 years ago. That’s a long time to keep worrying away at an analogy without any particular success anyone can point to. Maybe the mapping just isn’t that great.

I don’t mean we shouldn’t steal ideas from established engineering fields – this is a podcast that’s all about stealing ideas! – but I’m put in mind of Picasso’s saying, quote “Bad artists copy. Great artists steal”. Stealing is great! Sure, steal away! But 54 years of attempts to copy is enough. Time to move on.

Speaking of moving on…

Galison is vague about how the autonomous subcultures of physics, like experimenters and theorists, create the overall culture of physics. He writes things like, quote, “[Physics subcultures] can […] understand that the continuation of exchange is a prerequisite to the survival of the larger culture of which they are a part.” That sounds kind of hand-wavey to me, because real-world, pidgin-type trading zones are absolutely *not* about creating a larger culture. Really, they’re the opposite: they’re about having as little a, quote, “larger culture” as you can get away with and still conduct trade.

Trading zones are places where *barter* takes place. Barter – despite what you may have heard – is not the system that predated the use of money in societies. It’s a pretty rare economic system, and it takes place exclusively (or nearly exclusively) at the intersection of mutually-distrustful cultures.

In the show notes, you can find a paper by Davis Baird and Mark S. Cohen that points out that barter, or trade in commodities, is a poor metaphor for the creation of a larger culture. They say a better model is a *gift economy*. They use a history of medical MRI (magnetic resonance imaging) as an example. They conclude:

quote

“Ultimately there are three reasons [the stability of science] requires gifting. First, without a general sense of shared purpose traders will not be committed to mutual engagement; profit does not provide an adequate shared purpose for the MRI community. Second, stability requires trust, and profits are not an adequate foundation for trust. Finally, knowledge is a gift that will not keep on giving if treated simply as a source of profit.”

Now, at least since Eric Raymond’s influential paper about open source, “Homesteading the Noosphere”, the software community has had a distorted and oversimplified idea of what a gift economy is. So I’m going to devote the next non-interview episode to gift economies.

See you there, I hope. Thank you for listening.