Re: [eclipse-clp-users] Possible bugs solving FlatZinc problems

Roberto Castañeda wrote:
> Hi!
> 
> I have started to build a random generator of FlatZinc constraint problems and
> I am comparing the output given by different solvers (ECLiPSe, Gecode, JaCoP,
> etc.). During the first runs, I detected a couple of discrepancies between 
> ECLiPSe and the other solvers which I think are worth reporting:
> 
> 1) This FlatZinc input:
> 
> var 8..9: v4 :: output_var;
> constraint int_gt(v4, v4);
> solve maximize v4;
> 
> gives this output in ECLiPSe:
> 
> % Starting search
> Found a solution with cost -8
> v4 = 8;
> 
> While the other solvers report 
> =====UNSATISFIABLE=====
> 
> (The same happens with boolean variables and/or *_lt constraints).

Thanks for reporting this.  It's a bit mysterious, as the Minizinc
version works fine.  Also, the fzn_fd solver works ok.


> 
> 
> 2) This FlatZinc variable declaration:
> 
> var -6..-5: v1 :: output_var;
> 
> produces a parsing error in ECLIPSe:
> 
> pipe stream input: syntax error: postfix/infix operator expected
> | var -6..-5: v1 :: output_var;
> |         ^ here
> Error: Unexpected end of FlatZinc input
> Aborting execution ...

That's a consequence of lib(flatzinc) re-using the ECLiPSe tokenizer,
which requires a space between two symbol-tokens (.. and - in this case).
The Flatzinc report isn't explicit about tokens, and the mzn2fzn
translator seems to put the spaces in.  So there is no problem when
using Flatzinc generated from Minizinc, and I'm a bit reluctant to
slow down the flatzinc-reader.  Could you generate the space in
your flatzinc generator?


> If I am not missing anything and these are bugs, I can report them in the
> Bugs Database, I just wanted to make sure I would not be adding noise to it.

I have added them as #704 and #705.


-- Joachim