The other day, after going to an art / mi panel I was inspired to finish the book “An Engine, not a Camera: How Financial Models Shape the Markets, by Donald MacKenzie.  I had read deeply into the philosophical nature of models in the past particularly the work of Eric Winsberg, but I sort of left it without any breakthrough in my own thought.  Im sure I have blogged about it here, the different types of models that exist, what they measure, the guardrails that allow them to create ‘knowledge’, but it still left me with questions around what models did, and what computers/computation did for models.

An engine not a camera refers to the notion of models, like black-sholes (the options formula), are engines that analyze reality rather than images that represent reality. So when we say E=MC2, that is not a image of energy but it is a way to analyze reality in terms of energy and mass and the speed of light. You might say, well, this is just like a point of view, or a framing, but that is not the case. It is more like a reduction, like desaturating a color photograph and making it black and white.

Models are a reduction. they reduce the world to a number of variables. Models create a representation of the world as expressed by these limited variables and the their interactions as specified in the model.

But while reading this book, I came to the thought that what made a model powerful or adaptable was its ability to generate patterns.  Black-Sholes became used in the trading pits of Chicago, once various trading patterns could be extrapolated from it, such as the spread.  In fact there is a wide variety of ways I can generate trading patterns from options.

What is this relationship between patterns and models?

For instance, it is this ability to form patterns that allows us to think about options trading as replicating a portfolio, in a way similar to  CAPM. It is the patterns of model use that allow us to form equivalencies between different models.

I started thinking about patterns long ago when I was a summer intern at the Federal Reserve of Chicago and I was given a book to read: Design Patterns: Elements of Reusable Object-Oriented Software. This outlined a number of ways to create object oriented software, there were repeated patterns that people used. I still use this book and the patterns from it today.

We cannot really call oriented software design a model, but we can probably call a computer program a model. A machine learning algorithm is a model, but a model plus and maybe that means it is not a model (I’ll discuss that in a future blog post).

A computer program is a model, in the same way that a mathematical formula is a model, and all computer programs are just expanded lambda calculus – so these two concepts are closely related.

Back to patterns, perhaps what makes a model good (or correct or better), is not its error, its fitness, or some other thing, but its ability to generate patterns of usage. These patterns can then connect the model to other models, or be used in a wider variety in instances and exhibit more flexibility (which perhaps is a good standard for a model).

A model is an engine for analyzing. What does analysis do? What is the difference between analysis and representation? If in the past our artists were artists of representations, what would it be to be an artist of analysis?