# Functions and Partial Orders

In a few other blogs (especially here), there has been some discussion of the mathematical foundations of functions in programming languages, starting from topology. Just for fun, I will approach from the other direction, describing functions that can be defined in various languages in terms of partially ordered sets. Of course, for those of you who know this already, then you can go on and define topologies on these posets a la Dana Scott, so it amounts to the same thing. But this way has more pretty pictures.

### Functions and Partial Information

Suppose we want to look at functions from the natural numbers to the natural numbers. (By the natural numbers, I mean non-negative integers.) There are, of course, infinitely many such functions. Let’s pick a few that are interesting:

- The constant function
*f(x) = 5*. - The identity function
*g(x) = x*. - The successor function
*h(x) = x + 1*. - The doubling function
*p(x) = 2x*. - The square function
*q(x) = x*.^{2}

That should give us a good start. These functions are all quite well-defined over the integers. Indeed, I can implement them all in my favorite programming language, and I’ll get exactly that (note: only because my favorite programming language does arbitrary precision integers, of course.)

The next question is this: what happens if I don’t know everything about the input to the function? What can I infer about the output given *partial* information about the input? Here’s some of the things I might ask of that sort:

x |
x = 2 |
x is even |
x is at least 5 |
x could be anything |
---|---|---|---|---|

f(x) |
f(x) = 5 |
f(x) = 5 |
f(x) = 5 |
f(x) = 5 |

g(x) |
g(x) = 2 |
g(x) is even |
g(x) is at least 5 |
g(x) could be anything |

h(x) |
h(x) = 3 |
h(x) is odd |
h(x) is at least 6 |
h(x) is at least 1 |

p(x) |
p(x) = 4 |
p(x) is even |
p(x) is at least 10p(x) is even |
p(x) is even |

q(x) |
q(x) = 4 |
q(x) is evenq(x) is a perfect square |
q(x) is at least 25q(x) is a perfect square |
q(x) is a perfect square |

Getting back this sort of partial information is trickier than implementing the function over totally known arguments. That’s what this blog post is about.

### Partial Orders and Up-Sets

The trick is to build a partial order on the domain of the function. A partial order is some relation, ≤, that has three properties:

**Reflexive:**For all*x*,*x*≤*x*.**Anti-symmetric:**If*x*≤*y*and*y*≤*x*, then*x*=*y*.**Transitive:**If*x*≤*y*and*y*≤*z*, then*x*≤*z*.

Everyone is familiar with the ≤ that means “is no larger than.” But there are other perfectly good definitions as well. For example “is a factor of” is a perfectly good meaning for ≤. Now here’s where the pretty pictures come in. We can draw a diagram for a partial order, where there’s an upward path from *x* to *y* precisely when *x* ≤ *y*.

For example, here is part of the diagram for the familiar partial order “is no larger than” on the natural numbers:

And here is part of the diagram for “is a factor of”:

Each of these partial orders contains some information about the relationships between natural numbers. In particular, one can identify certain properties of the natural numbers as belonging to *up-sets*: sets that have the property that if they contain something, they also contain everything that it greater than it. So “at least 5” is the up-set of naturals in the familiar order that contains 5 and everything above it. We can call this the up-set *generated by* 5. In the second (divisibility) order, the up-set generated by 5 can be described as “divisible by 5”.

To use these orders to get information about partial inputs to functions, we need two things:

- Up-sets that capture the partial information we have.
- Functions that preserve that order.

Let’s shoot for the first one. Looking at the kinds of partial information we had:

*x*is even. This is the up-set generated by 2 in the divisibility order.*x*is at least 5. This is the up-set generated by 5 in the familiar order.*x*could be anything. This is the up-set generated by the bottom element of*any*partial order we like, so long as it has a bottom element.*x*is a perfect square. We’ll need a quite complicated order for this one. We can order the natural numbers by the divisibility order on the least common divisor of the exponents of their prime factorizations. It turns out this isn’t even a valid partial order (it violates anti-symmetry), but I can treat it as a partial order on equivalence classes, and things work out. Then perfect squares are the up-set generated by [2] (the equivalence class of numbers whose gcd of the exponents in their prime factorization is precisely 2) in this order.

Once we’ve chosen a partial order whose up-sets capture the information we want, we have to verify that the function actually preserves the order. That is, if we take an up-set generated by *x*, and pass everything in it through the function, will the result live in the up-set generated by *f(x)*. The successor function *h(x) = x + 1* that we defined earlier has this property in the familiar order. If I have a set of all numbers bigger than 4, and I add one to them all, I get all the numbers bigger than 5. However, *h(x)* does not preserve up-sets in the divisibility order. If I have all numbers divisible by 3, and I add one to them all, there’s no guarantee that the resulting numbers will be divisible by 4! So I have to be careful about using an order-preserving function, if I want any kind of partial information from up-sets.

What a mess! Sure, if I can define the right partial order, and then prove that the function preserves up-sets on the partial order, and sometimes pull this trick with equivalence classes, and then I get to say something about the behavior of my function on partial information. But that seems less than fulfilling somehow. It feels like I’m working too hard, and now I can’t even define some functions, depending on which order I choose.

### Sorting Out the Mess

So what do we do with all of this?

The first thing to do is to pick an order and stick with it. We’ll lose some partial information, but we’ll get to keep other partial information. The logical choice for natural numbers is the familiar order. It’s fairly common for me to want to know that a number is at least 3. It’s somewhat less common for me to want to know that a number is a multiple of 3. But I won’t assume any choice, and in a future blog post, I’ll demonstrate how to build numeric data types in Haskell that parallel several possible choices, and exhibit different laziness characteristics as a result.

The next thing we want to do is recover the ability to define all functions again. The problem with defining some functions is that there’s something “greater than” the number we’re looking at that won’t stay that way once we’re done. The obvious solution is to just make sure there’s nothing “greater than” a number. We can invent a whole set of pseudo-numbers: ~0, ~1, ~2, and so on. Then we’ll put the numbers themselves above that. Here’s the new set of natural numbers with the familiar order:

And voila! I can define all my favorite functions with the actual numbers. What remains is to extend my function onto the pseudo-numbers as well. In this order, the pseudo-number ~*n* means “at least *n*“. There’s always one safe way to do this: just map everything to ~0, the minimal element. However, if I still want to get partial information about the function, I need to do better.

Here’s the result for the divisibility order:

Here we have the same thing, except that “~*n*” now means “divisible by *n*“. Again, I need to extend my functions to the pseudo-numbers. I can still map everything to the bottom element (in this case, “~1”), but this throws away any partial information I may have been keeping.

Finally, one more option. This corresponds to a partial order on an equivalence class, sort of like what came out of the perfect squares example. This one, though, is the trivial equivalence class that lumps everything together. The result is the strict natural numbers, in which I must know the entire number to get any information out of any (non-constant) function.

Here only a constant function could do anything except map ~0 back to ~0. Therefore, unless your function is constant, the only way to get any information back from your input is to know the precise value of the input. This is an important arrangement of the natural numbers because for efficiency reasons, in the particular case of integers, this is precisely what all real programming languages do. We’re just using natural numbers as an example, though; the ideas here apply equally well to more complex structures where laziness exists.

It turns out, now, that once we’ve chosen a partial order for the pseudo-numbers, there is sometimes a best possible way to extend any function over the naturals to include pseudo-numbers. To determine the value of any function *f* at ~*n*, we’d like to find the greatest lower bound of *f(x)* for all *x* ≥ *~n*. Now if the partial order we chose happens to be something called a *complete meet-semilattice* (all of the orders we’ve talked about are), then that greatest lower bound exists.

### Connections to Programming Languages

As you may have guessed by now by my occasional references, this is all connected to laziness of functions in programming languages. I had intended to write about that now, but this has gotten too long already, so I am instead going to stop here and finish the other half at a later time. Hope you enjoyed it!

DNS client and server implementations will typically discard non-matching responses and continue to wait for a matching response. ,