In this series, we’ve been playing with the mathematical notion of an operator, seeing if we could make it useful for making a bridge between arithmetic and algebra. In the previous post, we started to investigate the notion of a function, and highlighted a key idea of the notion of a function that often goes unspoken both at the secondary school level and at the college math level. There is a name for this notion, but surprisingly this name is primarily used in the field of economics, and not much in mathematics or physical sciences. This name is ceteris paribus and is often translated with “other things being equal”. In economics, when you say that the number of Toyota Prius you sell is a function of their price, you are well advised to qualify your statement with an “all other things being equal”, precisely because the other things rarely are equal: a well-publicized scare about the brakes in an different Toyota model may be enough to throw off the sales numbers of the Prius without any change in their price at all. Or a sudden change in the price of a competing car model might equally alter the sales numbers of the Prius. A box as shown on the left:
seems seriously lacking. The box on the right is an attempt to clean this up a bit. Sales are not a function the price. From a known price, the sales volume is not uniquely determined. In the language of our operators and our state machine black boxes, we’d say that there are hidden variables or hidden state that affects the output.
The issue here, by the way, is not that the description inside of the box (“Prius”) doesn’t tell us precisely enough how to calculate the sales demand from the price as a given input. For all we know, the Prius box contains an big look-up table with the data from some massive earlier experiment in which prices were varied. Such a look-up table would be a fine way to build a function box. The issue, rather, is that price clearly isn’t the only thing that determines sales volume. Yet if we do manage to hold all the other potentially relevant variables constant – in other words, if we can really deliver on the ceteris paribus, then, yes, we’d have an example of a function.
In the previous post we also emphasized that a function doesn’t necessarily have its own matching undo. But let’s be more precise: a function doesn’t necessarily have a matching undo function. Computer programs often build undo-functionality by squirreling away some extra data. For example, if you delete a word, and then “undo” that delete, the program can retrieve the word that you deleted since it didn’t really delete it, it just squirreled it away. This copy of the deleted word is then part of the state of the machine, part of what is usually known as hidden state. By looking closely at how a program like Microsoft Word behaves, you can make up a decent model for what is going on. Microsoft Word operates on state, and the state is not just what is currently in the document, but also what is in its undo and redo stack. When you start Word, or whenever you save a document, these stacks are emptied. When you do something in Word, like typing, or deleting, or changing the font of a selection, an entry is added onto the undo stack, and each entry is specific enough so that the action can not only be undone, but also be re-done after undoing it. When you undo something, the last entry is moved from the undo stack to the redo stack. These stacks of undo/redo entries are fully part of the state on which Word operates.
For the mathematical notion of a function, it is essential that there be no hidden variables, that all dependencies are shown. So when we write , we think of x as the input, y as the output, and while we may at times insist that a,b,c are not variables, we nevertheless make them explicit, and give them some kind of appropriate name (parameters, or unspecified constants) that indicate that we think of them as fixed. In we have a different situation, where is thought of as a name for a specific number, or perhaps as a shorthand for the decimal expansion of that number.
OK – so now let’s briefly introduce properties, and then come back to those in more detail as well. Our starting point will be a state machine, one of the type we introduced in part 6 of this series:
A state machine has one or more buttons that invoke operators; when invoked, such an operator takes the current state of the machine, operates on it, and produces a new, updated state. Not all of the state is necessarily visible; typically, what shows on the screen is only a small portion of the machine’s state. Even on the simplest four-function calculator, there is a number being kept in the calculator that the screen does not show. If you enter “2+3=”, then at the moment the “3” shows on the screen, the ‘2″ is no longer showing – but we all know it is still “there” in some sense; after all, when you hit the final “=” button, the screen will show “5”, so clearly more was ‘kept around’ than just that “3”. And yet, clearly, what is shown on the screen depends on the state of the machine. In fact, what’s shown on the screen is an aspect of the state, a piece of the state, a component of the state. Here, we’d say that the screen content is one of the properties of the state.
We can look at properties as special kinds of functions, ones that usually don’t have an undo function. These functions can act on state, as in our example of the calculator screen above, or they can act on numbers, as in many of our examples of operators. Imagine a box that determines whether the number on its input is even or odd, and puts a value on the output accordingly – this will be an example of a property operator, and one we will pursue in an upcoming post.