Model the non-negative even integers Roger L. Costello March 24, 2018

Sets are really important in Alloy Alloy’s foundation is sets and set operations (join, union, intersection, difference, closure, etc.). You probably know that sets have been thoroughly worked out by mathematicians. That means Alloy has a really strong foundation.

3 ways to specify a set If you pick up a math book about sets, one of the first things you will learn is that there are 3 ways that sets can be specified: List (enumerate) its members. State a property which an object must have to qualify as a member of it. Define a set of rules which generate its members. Using each of those 3 ways, let’s create a model of the set of non- negative even numbers. After creating the models we will use the Alloy Analyzer to compare two models for equivalency (i.e., do the models generate the same instances).

Problem statement Model this instance: 0, 2, 4, …

List Model

Let’s start simple. Instead of modeling an infinite list, let’s model this finite list: 0, 2, 4, 6. one sig Non_negative_even_integers { members: set Int } fact List { Non_negative_even_integers.members = 0 + 2 + 4 + 6 } run {} The signature declaration defines a set named Non_negative_even_integers. The set has just one member. It has one field called members whose value is a set of Int (integers). The fact constrains the content of members to (0, 2, 4, 6).

one sig Non_negative_even_integers { members: set Int } fact List { Non_negative_even_integers.members = 0 + 2 + 4 + 6 } run {} The plus symbol ( + ) means set union. 0 and 2 aren’t sets, right?

one sig Non_negative_even_integers { members: set Int } fact List { Non_negative_even_integers.members = 0 + 2 + 4 + 6 } run {} The plus symbol ( + ) means set union. 0 and 2 aren’t sets, right? Answer: In Alloy each value is a set, i.e., 0 is {0}, 1 is {1}, and 0 + 1 is the union of the set {0} with the set {1}, yielding the set {0, 1}.

Predicate Model

This model will be better than the last model The list notation can only specify finite sets. The predicate notation can specify infinite sets.

Defining properties The predicate notation specifies a set by giving the properties that an object must have to be a member of the set. In our case, an object must have these two properties: The object must be an even integer. The object must be a non-negative integer. These are called defining properties.

Here is the Alloy model one sig Non_negative_even_integers { members: set Int } fact Predicate { Non_negative_even_integers.members = {i: Int | i >= 0 and (rem[i,2] = 0)} } run {} for 1 but 8 Int The fact uses a set comprehension to specify the members: The set of all integer i such that i is greater than or equal to 0 and the remainder of dividing i by 2 is 0. 8 Int does not mean 8 integers. It means an 8-bit signed integer. The range of values for an 8-bit integer is -128 to +127.

Generator Model

Number line Suppose there is a model of a number line in which each integer i is connected to i+2 1 2 3 4 5 -1 -2 -3 -4 -5 If we have that, then the desired set of integers can be modeled as: The chain in the number line which starts at 0.

How to model a number line? It is better to model a number line as a sequence and each integer i is connected to i.next and i.prev rather than i+1 and i-1. Here’s why: Since computers are finite, instances are also finite. Instances modeled by adding 2 to each integer will eventually fail with arithmetic overflow or with addition circling around to negative values. So, instead of an instance connecting i to i+2, the instance connects i to the integer that is two steps away in the sequence: i.next.next

Here is an Alloy model of the number line: one sig NumberLine { connections: Int -> Int } The signature declaration defines NumberLine with a field called connections. The value of connections is a set of (int, int) pairs. The arrow operator ( -> ) means “all possible combinations of the set on the left of the arrow with the set on the right of the arrow.” You might remember from your high school math class that this is called the cartesian product.

Don’t want the value of connections to be all possible (int, int) pairs We only want (i, i.next.next) pairs. The following fact constrains the pairs: For all integer i the value of the i’th connection is i.next.next fact Chain { all i: Int | NumberLine.connections[i] = i.next.next } Note: these two are equivalent: i.(NumberLine.connections) NumberLine.connections[i] The latter is just syntactic sugar for the former.

We are ready to model the desired list of non-negative even integers The value of members is the chain starting at 0: one sig Non_negative_even_integers { members: set Int } fact Chain_starting_at_0 { Non_negative_even_integers.members = 0.*(NumberLine.connections) } The reflexive transitive closure operator ( * ) means “in a set of pairs, wherever there is a pair (A, B) and a pair (B, C), then add these pairs: (A, A) and (A, C).” In other words, create pairs for all the values that A can reach, including itself. For our case, the set of pairs contains (0, 2) and (2, 4), so the * operator will add these pairs: (0, 0) and (0, 4). 0.*(NumberLine.connections) means “all the integers that can be reached from 0,” which is: 0, 2, 4, 6, …

Equivalence of the Predicate and Generator Models

Predicate model & Generator model The predicate model concisely represents (models) the list: 0, 2, 4, 6, … The generator model likewise concisely represents (models) the list: 0, 2, 4, 6, … We would like to show that the two models are equivalent; that is, they both represent (model) the same instance.

Need to show the instances are the same To show that the predicate and generator models are equivalent, we must express this: If the instances satisfy the predicate constraints, then the instances satisfy the generator constraints and vice versa. So, the constraints must be applied conditionally. Clearly, we cannot package up the constraints in facts because constraints in a fact cannot be applied conditionally.

Constraints in a pred are only applied when pred is called The purpose of pred is to package up constraints. The constraints are not applied until the pred is called. These 3 models all specify that instances must satisfy constraints A, B, and C: fact Some_Constraints { A, B, C } run {} pred Some_Constraints { run Some_Constraints pred Show { Some_Constraints run Show

Put constraints in preds Below is the Alloy code for the predicate model and the generator model. The predicate constraint is in a pred named Predicate. The generator constraint is in a pred named Generator. pred Predicate { Non_negative_even_integers.members = {i: Int | i >= 0 and (rem[i,2] = 0)} } pred Generator { Non_negative_even_integers.members = 0.*(NumberLine.connections) }

We want to express this We want the Alloy Analyzer to constrain the instances per the constraints in Predicate and then determine if each instance satisfies the constraints in Generator. Hey Alloy Analyzer, if there is an instance that satisfies Predicate but not Generator, then show that instance. Also, we want the Alloy Analyzer to constrain the instances per the constraints in Generator and then determine if each instance satisfies the constraints in Predicate. Hey Alloy Analyzer, if there is an instance that satisfies Generator but not Predicate, then show that instance.

Alloy assert In other words, we want to assert: For each instance that satisfies the constraints in Predicate, the instance will satisfy the constraints in Generator, and vice versa. The way to state assertions is with the assert. Here’s how to express the assertion: assert Equivalent { Predicate iff Generator } It says this: If an instance satisfies the constraints specified in Predicate, then the instance will also satisfy the constraints specified in Generator, and vice versa. In other words, the instances represented by Predicate are the same instances represented by Generator. When the Alloy Analyzer is requested to check the assert, it responds with, “No counterexample found.” In other words, the Predicate model and the Generator model are equivalent. Wow!

“run” a model, “check” an assert Use the run command to get the Alloy Analyzer to generate the instances that satisfy the model. Use the check command to get the Alloy Analyzer to execute an assert.

one sig NumberLine { connections: Int -> Int } fact Chain { all i: Int | NumberLine.connections[i] = i.next.next } one sig Non_negative_even_integers { members: set Int } pred Predicate { Non_negative_even_integers.members = {i: Int | i >= 0 and (rem[i,2] = 0)} } pred Generator { Non_negative_even_integers.members = 0.*(NumberLine.connections) } assert Equivalent { Predicate iff Generator } check Equivalent Do Lab4