Wednesday, August 13, 2014

Two models of mathematics

I've been thinking lately about high-level parallels between three activities I engage in on a regular basis: philosophy, mathematics and computer programming. One of the obvious things that all of these have in common is that abstraction has a role, though what role it has differs between the three and within each, depending on what one is doing.

One model of mathematics is the abstractive model. "Aristotelian" is a label that comes to mind. Natural numbers abstract from pluralities, ratios abstract from pairs of natural numbers, fields abstract from arithmetic, morphisms abstract from homomorphisms, categories abstract from just about everything. There is an old category theory joke that mathematicians are so absent-minded because mathematics is all about the application of forgetful functors. Taking the joke's thesis literally probably isn't going to give an adequate picture of, say, the number theorist or harmonic analyst are doing, but the basic picture is clear: mathematicians abstract away, or forget, structure. Pluralities have all sorts of structure: these four cows have legs, spots, give milk, and have one dominant cow, but we forget about everything but the "four" to get numbers. When we go from pairs to ratio, we forget everything but the multiplicative relationship. And so on up.

The other model of mathematics is the constructive model (using the term very loosely, and without a commitment to constructivism). Here, we build our way up to more complex structures out of simpler ones. The most impressive example is just how much of mathematics can be seen as about sets and membership.

The abstractive model makes one think of very high level programming languages, of paradigms like functional programming or object-oriented programming. The constructive model makes one think of assembly language programming (some will lump C in here, and I guess that's not unfair). The models can be thought of as models of practice. If so, then they are complementary. Both with computers and mathematics, we need both the abstractive and the constructive practices. We need Java and assembly programmers; we need category theorists and real analysts. Different solutions are appropriate to different problems. You are unlikely to do a lot of abstraction when producing hand-optimized code for an 8-bit microcontroller, but you won't want to produce a banking system in this way. The abstractive approach ("abstract nonsense", as it is fondly called) is just the right thing for many (but not all) problems in algebra, but a constructive approach is likely to be the better solution for many (but not all) problems in harmonic analysis. And of course really good work can involve both, and a well-rounded programmer and mathematician can work in both modalities.

But besides thinking of the two models as models of practice, one can think of them as models of ontology. There is an abstractive ontology of mathematics. Mathematical facts are simply abstractions from facts about concrete things. And there is a constructive ontology, the most prominent starting with sets and showing how the mathematics we care about can be made to be about sets.

With computers, it's clear that the analogue to the constructive ontology is simply the truth of the matter. Computers are built up of transistors, the transistors run microcode, the microcode runs higher level machine code, and all the way up to Java, Haskell and the like. That elegant Haskell one-liner will eventually need to be implemented with microcode. And we have tools to bridge all the levels of abstraction. The proponent of the set-theoretic ontology in mathematics says that the analogy here is perfect. But that is far from clear. We need to take seriously the idea that mathematical abstractions are not built up out of simpler mathematical entities, but are either fundamental or are grounded in non-mathematical entities and pluralities (and their powers, I will say).

Nothing new here. Just laying out the territory for myself.

No comments: