Added library files for edit distance global

[IXI01]

Here is the minizinc code for the edit distance global constraint that we introduced together with Peter in the AAAI 2020 paper "Explaining Propagators for String Edit Distance Constraints". It would be great if it could be included in future releases. If I should do anything else just let me know.

All the best,
Felix Winter

[guidotack]

Thanks, looks good! Just a few things to fix:

• To be included in the library, you would have to separate the actual decomposition from the modelling interface, by splitting it up into the edit_distance and fzn_edit_distance predicates. The linear version would then only override the fzn_... version. See e.g. cumulative for what this should look like.
• Anything that should be checked statically should be done via assertions rather than constraints. I noticed that you e.g. have the constraint u1=u2, which would mean that the constraint currently is simply false for arrays of different size. I think this should be an error instead.
• Does the constraint currently assume that the index sets of the arrays start at 1? Either this would also have to be checked by assertions, or (preferably) the constraint should work for index sets that don't start at 1.

[zayenz]

I just looked at the documentation of the proposed predicates (not the actual implementation), and I'm wondering if it would be possible to let the ED variable be equal to the edit distance, instead of just larger than or equal?

[IXI01]

Thank you Guido for the feedback.
I now split the actual modelling interface and decompositions into separate files. Furthermore, I added several assertions including the mentioned u1=u2, which is not part of the constraint any longer. Also arbitrary index sets are now supported as long as both arrays have the same length (which is asserted). Additionally, I updated my pull request to the chuffed repo accordingly.

@zayenz: Although it would be possible to enforce ED to be equal to the minimum edit distance, it would make things harder and the decompositions would potentially require many more variables/constraints. We found out empirically, that it is often easier to efficiently constrain the edit distance to be "legal" (i.e. >=) and let the solver do the minimization, which was anyway implied by the minimization goal for the two applications we dealt with. One could think about providing an extra predicate that enforces ED to be exactly the minimum edit distance in the future though (although I cannot think of an application that needs this at the moment).

[zayenz]

@IXI01 Ok.

As for applications of having the exact edit distance, I can imagine that I would want to use a predicate like this to find strings with a specific edit distance or even maximizing the edit distance under some set of other constraints, for example for generating test cases or for ensuring diversity of solutions.

[IXI01]

@zayenz Thank you for the interesting comments! Since you pointed out some applications, I thought about this again, and actually the most general decomposition for the ED >= case also guarantees the precise edit distance (but only this one, not the linear decompositions, not the more specific cases which are more efficient, and not the chuffed propagator). However, as it is the most general decomposition it can easily be used for an "edit_distance_exact" global variant.

That's what I incorporated now, another global predicate that is exact and basically forwards any call to the most general decomposition. In the documentation I added a note that this one is likely to be less efficient than the standard cases.