Hi,

If you create a new LinearInt constraint by passing it a list of singleton variables that do not add up to the right-hand-side constant, then the constraint is incorrectly not imposed, and the store incorrectly claims to be consistent.

The issue is in commonInitialization(), which collapses all singleton variables into the right-hand-side constant b, which can result in the list of variables x becoming empty, and then impose() returns without imposing the constraint, even though it is violated because b != 0.

Best,

Thomas

Hi , when I try to compile the git hub repo, I get lots of errors like these:

• ASTSolveItem cannot be resolved to a type Solve.java /jacop/src/main/java/org/jacop/fz line 126 Java Problem
• JJTANNEXPR cannot be resolved to a variable SearchItem.java /jacop/src/main/java/org/jacop/fz line 119 Java Problem

These types seem indeed to be mssing in the repo.

There are other problems related to warning settings:

• The field Diff2.xmlAttributes is hiding a field from type Diff Diff2.java /jacop/src/main/java/org/jacop/constraints line 67 Java Problem
• override annotation missing

Although I could change my settings in eclipse to get rid of these, I wonder if it would not be better to fix these problems in the repo/source since they reflect recommended programming guidelines

Thanks for this great work !

Could you please publish git tags for releases? They seem to be missing for all releases except 4.0.0.

This would be helpful for me since I use JaCoP to test and benchmark ExtendJ, and I'd like to test it on all released versions of JaCoP.

As far as I can see, there is not "official" maven repository of JaCoP, but this one:

<dependency>
    <groupId>de.sciss</groupId>
    <artifactId>jacop</artifactId>
    <version>3.4.0</version>
</dependency>

See http://mvnrepository.com/artifact/de.sciss/jacop.

Could you place your library into maven, please?

Thanks for your work :+1:

In some situations, I'm having the problem that DepthFirstSearch causes a StackOverflowError due to an infinite recursion:

Exception in thread "main" java.lang.StackOverflowError
    at org.jacop.search.DepthFirstSearch.label(DepthFirstSearch.java:559)
    at org.jacop.search.DepthFirstSearch.label(DepthFirstSearch.java:765)
    at org.jacop.search.DepthFirstSearch.label(DepthFirstSearch.java:765)
    at org.jacop.search.DepthFirstSearch.label(DepthFirstSearch.java:765)
    // and so on...

I'd like to debug this, to find out whether this is a problem with my own code or a bug in JaCoP, but I don't know what information is useful to you. If you could guide me with this, that'd be great!

Edit: This is on JaCoP 4.3.0, as provided in the Maven repository (see #12).

Hi, I did build a scratch jacop package. You can see build and logs at http://koji.fedoraproject.org/koji/taskinfo?taskID=8450365 You can see the rpm spec at https://pcpa.fedorapeople.org/jacop.spec

I would like to ask for a LICENSE file inclusion in the sources. Also, if would be good if you could provide an official release tarball.

This is partly for my work on packaging ampl/mp https://github.com/ampl/mp/issues/19

When modeling the MagicSeries questions using Among JaCoP returns two solutions. However, it should only be one. Solution 2 seems to be wrong as the 1 appears twice.

Solution 1: 6 2 1 0 0 0 1 0 0 0 
Solution 2: 7 1 0 0 0 0 0 1 0 0 

Sample Code run with JaCoP 4.1 as well as 3.2

    int n = 9;
    Store store = new Store();
    IntVar[] vars = new IntVar[n+1];
    for (int i=0; i < vars.length; i++) {
        vars[i] = new IntVar(store, "H"+i, 0, n);
    }
    for (int i=0; i < vars.length; i++) {
        store.impose(new Among(vars, new IntervalDomain(i, i), vars[i]));
    }
    Search<IntVar> search = new DepthFirstSearch<IntVar>();
    search.setPrintInfo(false);
    SelectChoicePoint<IntVar> select =
        new InputOrderSelect<IntVar>(store, vars, 
                                     new IndomainMin<IntVar>());
    search.getSolutionListener().searchAll(true);
    search.getSolutionListener().recordSolutions(true);
    search.labeling(store, select);
    int numSolutions = search.getSolutionListener().solutionsNo();
    for (int i=1; i <= numSolutions; i++) { 
        System.out.print("Solution " + i + ": "); 
        for (int j=0; j<search.getSolution(i).length; j++) 
            System.out.print(search.getSolution(i)[j] + " "); 
        System.out.println(); 
    } 

Hi,

Can you please make the following fields of the Arithmetic constraint protected instead of private? I would like to subclass this class but not having access to these fields makes it impossible.

    private List<int[]> eqns;
    private List<IntVar> vars;
    private Map<IntVar, Integer> map;

Thanks in advance!

JaCoP 4.6.0

When an XneqC constraint is imposed on an IntVar with a BoundDomain, it can happen that the constraint is ignored and dropped, i.e. not considered in later consistency checks. This does not happen right away, but on the first consistency check.

Observed behaviour Consider an IntVar x with a BoundDomain in {-500; 500}. Now impose XneqC(x, 0). The first check of consistency brings us here https://github.com/radsz/jacop/blob/abe1e146e4661c8a6975c4607a84d21039b0fc82/src/main/java/org/jacop/constraints/XneqC.java#L80-L82

which delegates to

https://github.com/radsz/jacop/blob/abe1e146e4661c8a6975c4607a84d21039b0fc82/src/main/java/org/jacop/core/BoundDomain.java#L350-L357

which disregards the complement and just leaves the domain unchanged; but to make things worse, the XneqC is also never considered on later changes to X. It seems that the constraint is dropped.

Expected behaviour Modify the BoundDomain, or keep consulting the constraint when changes to the domain of X are made later. If all else fails, give a clear indication (runtime exception?) about the fact that this operation has failed.

Workaround Use an IntervalDomain instead of the BoundDomain – this circumvents the described problem, but I am not sure about the effect on other operations...

We were made aware aware by a MiniZinc user that set_le and set_lt are working incorrectly within the JaCoP solver: https://github.com/MiniZinc/libminizinc/issues/185

The following FlatZinc model returns incorrectly as unsatisfiable:

var set of 1..10: a ::output_var = {8};
var set of 1..10: b ::output_var = {7, 8, 9};

constraint set_le(a, b);

solve  satisfy;

Similarly for constraint set_lt(a, b);

Please change the signature of the Channel constructor from

Channel(IntVar x, Map<Integer,IntVar> bs)  

to

Channel(IntVar x, Map<Integer,? extends IntVar> bs)

This would make it possible to use the Channel constraint with variables that are expressed as subclasses of IntVar.

Bumps scala-library from 2.13.1 to 2.13.9.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Please change the signature of the Decreasing constructor from

public Decreasing(List<IntVar> x)

to

public Decreasing(List<? extends IntVar> x)

This would make it possible to use the Decreasing constraint with variables that are expressed as subclasses of IntVar.

The same applies to the following constructors:

public Decreasing(List<IntVar> x, boolean strict) public Increasing(List<IntVar> x) public Increasing(List<IntVar> x, boolean strict)

That report generation takes time, slowing down the overall build. Reports are definitely useful, but do you need them every time you run the build. We can conditionally disable generating test reports by setting <disableXmlReport>true<disableXmlReport>. If you need to generate reports, just add -DcloseTestReports=false to the end of mvn build command.

===================== If there are any inappropriate modifications in this PR, please give me a reply and I will change them.

The following code:

Store store = new Store ();
		
// Create the variables
IntVar cost = new IntVar (store, "cost", 0, 2);
IntVar[] vars = new IntVar [2];
vars[0] = new IntVar (store, "v_0", 0, 1);
vars[1] = new IntVar (store, "v_1", 0, 1);

// Ground the variables using In constraints, such that the store is infeasible
store.impose(new In (cost, new IntervalDomain (0, 0)));
store.impose(new In (vars[0], new IntervalDomain (0, 0)));
store.impose(new In (vars[1], new IntervalDomain (0, 0)));
		
// Impose a SoftAlldifferent constraint
store.imposeDecomposition(new SoftAlldifferent (vars, cost, ViolationMeasure.DECOMPOSITION_BASED));
		
System.out.println(store.consistency());

throws

Exception in thread "main" java.lang.AssertionError: non-optimal arcs:
[1->sink, flow=0/1  reduced=-1, index=2]
	at org.jacop.constraints.netflow.Assert.checkOptimality(Assert.java:269)
	at org.jacop.constraints.netflow.simplex.NetworkSimplex.networkSimplex(NetworkSimplex.java:368)
	at org.jacop.constraints.netflow.NetworkFlow.consistency(NetworkFlow.java:255)
	at org.jacop.core.Store.consistency(Store.java:547)

when asserts are enabled.

AmongVar.impose() initializes xGrounded to the number of X variables already grounded, but then calls super.impose(store), which itself calls AmongVar.queueVariable(), which again increments xGrounded for each singleton variable, resulting in each grounded variable being incorrectly counted twice.

Suggested bug fix: in AmongVar.impose(), initialize xGrounded to 0 (like is already done with yGrounded) instead of to the number of grounded variables.

Concerns : JaCoP 4.6 (Java 11).

I spotted a few issues in the code of the RegularExpressionParser class introduced in 4.6.

• (this one is fixed in the enclosed patched file) the class is unusable since the result of lexer.nextToken() is never used. As a consequence of that, any call to parse yields 'null'.
• The dot notation parsing is flaky. For instance, the following two examples relate toi the handling of epsilon expressions but are not orthogonal to one another.

// Prints "null.(32)*"
System.out.println(new PatchedRegexParser(new StringReader("(.32*)")).parse(false));

// Warns of a syntax error then prints "32.(null).*"
System.out.println(new PatchedRegexParser(new StringReader("(32.*)")).parse(false));

• In some cases (ie when a dot is missing) the parser silently drops a whole portion of the text to parse. For example, consider the following example:

// Prints "(17)*.23" and nothing more.
System.out.println(new PatchedRegexParser(new StringReader("(32.14*)17*.23")).parse(false));

Btw, I wonder if reusing the . and + symbols for summation and concatenation was judicious. Indeed, these symbols have different meaning in POSIX-style regexes (and I assume most people would expect that meaning)

PatchedRegexParser.java.txt