minizinc / minizinc-benchmarks Goto Github PK

Hi,

There are a lot of warnings when flattening the model mqueens2.mzn with any *dzn file. I'm using the last Minizinc distribution (2.0.13) without any solver specific global constraint definition.
I tried an older version (2.0.2) and the fzn file was generated without warnings.

This is the first warning:
Warning: undefined result becomes false in Boolean context
(array access out of bounds)
mqueens2.mzn:55:
in call 'forall'
in array comprehension expression
with i = 1
with j = 1
mqueens2.mzn:56:
in binary '=' operator expression
in unary 'not' operator expression
mqueens2.mzn:57:
in binary '/' operator expression
mqueens2.mzn:59:
in unary 'not' operator expression
in call 'exists'
in array comprehension expression
with k = 1
mqueens2.mzn:60:
in binary '/' operator expression
in unary 'not' operator expression
in array access

Thanks.

There are legal systems (for example in the US and in the EU) where copyright sticks to authors and just declaring that something is in the public domain is not enough to facilitate safe re-use (without accidental copyright infringement), see https://en.wikipedia.org/wiki/Public_domain#Dedicating_works_to_the_public_domain. In my understanding, the only reliable way for donors to work around their copyright is to provide a suitable license. For example, minizinc-examples are issued under the MIT license and hence it is safe to re-use, modify, and redistribute them.

I've tried to solve a problem from a YouTube video using MiniZinc.

% 
%  This model strives to solve the problem
%  discussed in a YouTube video of Michael Penn
%  
%  How large can a subset be???
%  https://youtu.be/ZOx_DMeHjyE
%
%  The solution shown is 905
%
int: n = 1989;

set of int: N = 1..n;

array[N] of var bool: select;

%  selected elements must not be 4 apart
constraint
    forall(i in 1..n-4) (not select[i] \/ not select[i+4]);
      
%  selected elements must not be 7 apart
constraint
    forall(i in 1..n-7) (not select[i] \/ not select[i+7]);      

var N: elements = sum(select);

solve maximize elements;

output ["\(elements) elements"];

The example is rather small. But I found that the various solver back-ends do have remarkably different run-times and optimization results.

The model tents.mzn makes the tacit assumption that the number of given trees is equal to the required number of tents.
Otherwise, the instance is ill-defined.
This holds for tents_1.dzn and tents_2.dzn but not for tents_3.dzn, which has 50 given trees but requires 51 tents.
I suggest to fix the instance as follows:

n = 16;
a = [| 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0
     | 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1
     | 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 0
     | 0, 0, 1, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0
     | 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0
     | 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0
     | 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0
     | 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0
     | 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1
     | 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0
     | 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0
     | 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 1

    %| 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
     | 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

     | 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0
     | 0, 0, 0, 0, 0, 1, 0, 1, 1, 0, 0, 0, 1, 0, 1, 0
     | 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
     |];
row_sums = [4, 3, 4, 2, 5, 2, 1, 7, 0, 3, 5, 2, 4, 3, 2, 4];
col_sums = [4, 1, 6, 1, 5, 2, 1, 7, 0, 5, 2, 3, 3, 4, 1, 6];

Retrieved this email from a user:

"Hi

I have started running all problems in the minizinc-benchmarks dataset.

I have found a few problems that do not compile with mzn2fzn or minizinc:

• latin square hybrid and latin square hybrid2
• data file jobshop vw3x3
• all nsp/ models
• model pattern_set_mining.mzn
• carseq,mzn
• mqueens2.mzn

[...]"

Used MiniZinc version was not stated in the email.