0

Given the following minizinc program:

var 0..4: a;
var 0..5: b;
var -5..2: c;
var -8..-3: d;
var 0..8: m;
var bool: r;
constraint r <-> m = max([a,b,c,d]);
solve satisfy;

and the redefinitions-2.0.mzn file

predicate array_int_maximum(var int: m, array[int] of var int: x);                                      
predicate array_int_maximum_reif(var int: m, array[int] of var int: x, var bool: r);                    
predicate array_int_maximum_imp(var int: m, array[int] of var int: x, var bool: r); 

I would expect to get a reified version as output of flattening, but I do get:

predicate array_int_maximum(var int: m,array [int] of var int: x);
predicate int_eq_imp(var int: a,var int: b,var bool: r);
var 0..4: a:: output_var;
var 0..13: b:: output_var;
var -5..2: c:: output_var;
var -8..-3: d:: output_var;
var 0..16: m:: output_var;
var bool: r:: output_var;
var -8..13: X_INTRODUCED_1_ ::var_is_introduced :: is_defined_var;
array [1..4] of var int: X_INTRODUCED_0_ ::var_is_introduced  = [a,b,c,d];
constraint array_int_maximum(X_INTRODUCED_1_,X_INTRODUCED_0_):: defines_var(X_INTRODUCED_1_);
constraint int_eq_imp(m,X_INTRODUCED_1_,r);
solve  satisfy;

How and where do I add the information that I do support the reif and imp version of this predicate, and therefore have a possibly faster handling than the automatic translation? (duplicate of this unsolved issue)

Max Ostrowski
  • 575
  • 1
  • 3
  • 15

1 Answers1

1

The simple answer is that array_int_maximum_reif is currently unused. It would have to be generated by the compiler, but the compiler instead chooses to just create a array_int_maximum constraint and use an int_eq_reif constraint.

It is still not fully clear when to reify a function. It is pretty clear that total functions should never be reified as it offers no additional benefits. For partial functions it is still a question when it is a good idea. max is a partial function in MiniZinc, but it is made total before it makes in to array_int_maximum. Hopefully there will be more information on this issue soon.

Dekker1
  • 5,565
  • 25
  • 33
  • Could explain a bit more why total functions should not exist in a reified context? Especially why it does not offer any benefit? Thanks a lot. – Max Ostrowski Jul 03 '21 at 08:13
  • It comes down to the propagation of the reification. When reifying a total function, the propagation of that reification must first calculate the values still valid for the result of the function, and then depending on the control variable enforce if the value in the reification takes that value or cannot take that value. Since these two parts are exactly equivalent to actually propagating the function and an equality reification, there is no computational overhead into splitting them up. And from the MiniZinc perspective reduces the amount of implementation required from the solvers. – Dekker1 Jul 04 '21 at 01:01
  • While this is correct in terms of propagation complexity, this can be problematic for solvers that translate to e.g. SAT, as a new integer variable is introduced, which needs additional (Boolean) variables and constraints (number dependent on the encoding). And as it is not mandatory to support the _reif version it is no burden on the amount of implementation of the solver but gives the possibility to save variables and constraints. – Max Ostrowski Jul 04 '21 at 07:06