0

About option types, the specification of Minizinc (sec. 6.6.3) says:

Overview. Option types defined using the opt type constructor, define types that may or may not be there. They are similar to Maybe types of Haskell implicity adding a new value <> to the type.

[...]

Initialisation. An opt type variable does not need to be initialised at instance-time. An uninitialised opt type variable is automatically initialised to <>.

I would like to parse and process the following constraint with two opt types:

predicate alternative(var opt int: s0, var int: d0,
                      array[int] of var opt int: s,
                      array[int] of var int: d);

However, I am not sure about what should I expect as values for arguments s0 and s when parsing this constraint.

Can I simply ignore the presence of the opt modifier and assume the constraint signature to be equal to the following one?

predicate alternative(var int: s0, var int: d0,
                      array[int] of var int: s,
                      array[int] of var int: d);

If not, how should I handle it?

Patrick Trentin
  • 7,126
  • 3
  • 23
  • 40
  • `var opt` can be quite tricky to just use, and I reckon it's even worse to parse and handle then further. Perhaps you should ask this at http://www.minizinc.org/forum.html . It's a bit closer to the MiniZinc developers. (Are you implementing a FlatZinc solver for OptiMatSAT? I hope you make it public available.) – hakank Nov 03 '17 at 20:59
  • 1
    @hakank I'll try on that board, thanks. OptiMathSAT already has an interface for a subset of the FlatZinc language since version 1.4. Currently, we extending this interface to cover some more global constraints, for performance reasons, and testing various encodings. – Patrick Trentin Nov 03 '17 at 21:03
  • Ah, I have have missed that. Will test it ASAP. :-) – hakank Nov 03 '17 at 21:05
  • @hakank I wouldn't say that at its current stage it's something to get terribly excited for, but I thank you for your interest. If you happen to find any bugs, on our website you can find a contact email for the reports. (: – Patrick Trentin Nov 03 '17 at 21:11
  • Will do. I'm testing it right now. :-) – hakank Nov 03 '17 at 21:18

1 Answers1

1

In MiniZinc variable option types are handled as variables that might not exist. Within the compiler these variables are transformed these variables are interpreted and rewritten in such a way that the FlatZinc output only contains actual variables. Usually this means that an boolean variable is added for every variable that is true if-and-only-if the variable "exists".

For the library writers, there is the option to rewrite it in such a way that your solver will be able to handle best. In the standard library alternative is defined as:

predicate alternative(var opt int: s0, var int: d0,
                  array[int] of var opt int: s,
                  array[int] of var int: d) =
          assert(index_set(s) = index_set(d),
                 "alternative: index sets of third and fourth argument must be identical",
          sum(i in index_set(s))(bool2int(occurs(s[i]))) <= 1 /\
          span(s0,d0,s,d)
      );

Notice that the occurs intrinsic is used to test if a variable exists. More intrinsics for variable types can be found in the MiniZinc library: http://www.minizinc.org/doc-lib/doc-optiontypes.html. If necessary, you can also use a let-expression to create extra variable and then map the predicate to an solver intrinsic predicate.

Even if there is no better decomposition of the optional type predicate for your solver, it can still be worthwhile to implement the predicate without option types. Because of MiniZinc's overloading, that implementation will be used whenever the predicate is called with arrays of non-option variable types. (Note though that the alternative predicate is specifically meant for "optional tasks" and is unlikely to be called that way).

Dekker1
  • 5,565
  • 25
  • 33
  • So, the *optional* part is not the `type`, but the `variable` itself: is it equivalent to the concept of optional arguments in `programming language of your choice`? When I see something like this: `array[int] of var opt int: s`, am I guaranteed that either there is no array `s` at all or all memory locations `s[i]` exist? In other words, does the language permit an array `s` with mixed *existing/non-existing* memory locations? – Patrick Trentin Nov 07 '17 at 15:56
  • @PatrickTrentin You might be misunderstanding what I meant. MiniZinc does allow for mixed *existing/non-existing* variables in arrays. Say that, for example, the array consists of the start time of a number of tasks, then that array would be `array[N] of int`. If I however don't know how many tasks there are, then I would have to do something different. In MiniZinc you would use a `array[N] of opt int` type, where `N` is the maximum number of tasks. If no tricks can be used then we produce an `int` and a `bool` variable for all `N` numbers, but often these booleans can be unified. – Dekker1 Nov 07 '17 at 22:43
  • @PatrickTrentin Note that MiniZinc and FlatZinc don't reason on memory locations, but variables. The implementation of these variables is up to the solver. It might also be good to know that optional variables are usually the result of array comprehensions with variables in the where clause. – Dekker1 Nov 07 '17 at 22:46
  • I made some tests and I actually understood how it works now, thanks for your help. – Patrick Trentin Nov 08 '17 at 19:31