Welcome to the reference material on enumerated types. So, an enumerated type defines a set of named objects. And it's very simple. We declare the name of the enumeration, just with this enum keyword, and then the name that we want to declare. And then we're going to give it a value by saying this new name is equal to some set of objects, given as a list inside. Braces, and of course, just like in other MiniZinc declarations, a declaration can be combined with the assignment in one line. And the idea is to use enumerated types, we can use them wherever we could use a set of integers or the keyword int. That's what being an enumerated type is, it's like a nameset of integers in other languages. So, we have to be aware of some restrictions on enumerated types. The objects inside enumerated types have to be a valid identifier, so this thing here <reddish> is not a valid identifier, and simply -3 is an integer, and not an identifier. You can get around that by using single quotes to make identifiers out of basically anything. And indeed, once you've got a single quote, you can use Unicode characters inside those to get complicated names, names for enumerated types, and other objects and complicated things in the enumerated type. Now, the key restriction on enumerated types is if we're using two or more enumerated types, then the set of objects that they talk about can't overlap. Right, so we can't have red as both a color and a condition. So, we can define a parameter or a decision variable of an enumerated type by giving the name of the type, colon, and then the parameter name. If I want to declare a decision variable, then I just put the var keyword in front. And of course, we can define arrays of those and arrays indexed by those. So here, we have color and condition enumerated types. And here is an array indexed by condition, so it's going to have three elements in the array of decision variables, which take values in color, so each of these decision variables can take four different values. So, we can also create range type definitions using the constants, enumconst1 to enumconst2 gives you a range, and that can be a variable or not. So, for example, blue::pink is basically the range from blue to pink, excludes the value red. And this decision variable y is from blue to green, so excludes the value of red and pink. So, enumerated types behave very much like integers. And basically, the enumerated type value is very similar, almost identical to inside,inside of where it will actually be. The integer value of the position in that list. So, red is really equal to one, blue is a name for two, green is a name for three, and pink is a name for four. And so, when we use and an enumerated type in a place where we are expecting integer, that's what happens. So, here this constraint has two solutions. X is red, and x is blue, because red is equivalent to one, and blue is equivalent to two. And that's what makes that constraint hold. So you can think about it as MiniZinc effectively adding a coercion from the numerator time contribute two value, whenever we use it in a place where we'd expect an integer. So, we can compare enumerated type values to their order by the order they appear in the declaration. So far, I write down this model here. I've got three, enumerated type color, variables. I've got x < y and y < z. And then there's four solutions. And you can see that red is before blue, is before green in this ordering. Blue's before greens, but pink. And there are degrees with the integer view. For the last one, this is the second value, the third value, and the fourth value. So, we've got some built in type functions. Built in functions, some enumerated types, the enum_next takes enumerated value x, the enumerated type, which we're working in and returns the next value after x. In that enumerated type. Enum_prev does the same, but returns the previous value. And we can coerce and integer to an enumerated type giving this to_enum built-in function, which will convert an integer value into some of this type enum. And there are existing operations that are applicable to enumerated types, like max of a set of enumerated type values, or min or cardinality. These are exactly as you would expect. Next, we have to be aware that these enumerated type functions are partial, so if I ask for the next enumerated function on x with x, where x is actually the last thing in this enumerated type, we are going to get back an undefined result. This is going to be handled just like every other undefined result, amazing. It's going to propagate failure to the nearest, inclusive boolean context. And enum_previous is undefined if x takes the first value of an enumerated type. And simply, if we coerce an integer i into a numerator type, and estimate it take a value from one to the number of values in that enumerated type. If it doesn't, then it kind of gets back to non-defined result. So, the normal uses of enumerated types are the values of variables indices of arrays. So, for example, our array of conditions given decision variable color. We can do things like that this. So, we can iterate for i on the minimum of condition, which is normal, to the previous of the maximum condition, which is the previous of alert, which is safe, all right? So, this is raising it from normal to safe. And it's going to set up constraints, x of i is less than x of enum_next of condition i. So, x of normal is less than x of the next of normal, which is safe, all right? And x[safe} is less than x[alert] its next. Almost any use of a enumerated type variable will actually coerce it to an integer. The exceptions are if you test for quality, and it remains an enumerated type. If you take the max/min, or you're indexing into an array. So, for example x[safe] is a type of COLOR and the max[normal..safe] is a type COND since that's max operation. But other examples will either try to quest to an integer or fail. So, an example here, we've got an array who's indexed by condition. But we're looking it up is an i, which is a dark color. Now, it's going to lead to an error message saying that we're using a index of type var COLOR, where wanted one of type COND. And this is really the strength of enumerated types is that if you have two enumerated types, and you use them in the wrong places, then you'll get an error message. And this is the advantage over previous ways of doing this, where we could have used numbers one to four to represent colors, and the numbers one to three. Represent conditions, and then this would not have lead to an error message, even though it's not, obviously doing something which is not what we're expecting. So, that can help avoid many subtle errors. So, in summary, enumerated types allow us to distinguish different sets of objects which are used in the model. And use these named constants to refer to as objects, and allows us to avoid mixing up sets of objects. And using enumerated types makes models more concise. We can write down a definition in just one line. Less buggy, because I find these errors are a mixed up sets of objects, and typically easier to understand. So, you should use them wherever applicable. And that brings us to the end of the section.
