Cannot understand cardinality constraint in clingo - constraints

I have the graph coloring problem defined in Clingo as so:
node(sa;wa;nt;q;nsw;v;t).
color(r;g;b).
edge(sa,(wa;nt;q;nsw;v)).
edge(wa,nt). edge(nt,q). edge(q,nsw). edge(nsw,v).
edge(X,Y) :- edge(Y,X).
and I have the solution characterized like this:
{assign(N,C) : color(C)} = 1 :- node(N).
:- edge(X,Y), assign(X,C1), assign(Y,C2), C1 == C2.
#show assign/2.
I cannot understand what the = 1 in the generate portion of the code means. I know that it is "set cardinality", but I do not understand how, as the code must generate seven nodes in each answer. Additionally, the following generator (which generates all combos of nodes and colors choosing in a set of length 7) requires an = 7:
{assign(N,C) : color(C), node(N)} = 7.
Here is a picture of the graph coloring problem I am solving: https://imgur.com/a/tX7qtkJ
and clingo: https://potassco.org/clingo/run/

{assign(N,C) : color(C)} = 1 :- node(N).
This means "choose exactly one color for each node". Or, more precisely, for
each node n, pick one color c such that assign(n, c) becomes true.
To understand this better, we need to dig into the semantics of ASP.
Here N occurs outside of the cardinality constraint, so it can be viewed
as a "global variable" in this rule. The rule is essentially a shorthand for:
{assign(sa,C) : color(C)} = 1 :- node(sa).
{assign(wa,C) : color(C)} = 1 :- node(wa).
{assign(nt,C) : color(C)} = 1 :- node(nt).
{assign(q,C) : color(C)} = 1 :- node(q).
{assign(nsw,C) : color(C)} = 1 :- node(nsw).
{assign(v,C) : color(C)} = 1 :- node(v).
{assign(t,C) : color(C)} = 1 :- node(t).
Now, this set {assign(sa,C) : color(C)} is just a shorthand for
{assign(sa,r), assign(sa,g), assign(sa,b)}.
Now, {assign(sa,r), assign(sa,g), assign(sa,b)}=1 roughly speaking means pick one element from the set {assign(sa,r), assign(sa,g), assign(sa,b)}.
If you look at clingo manual, the general syntax is
{assign(sa,r), assign(sa,g), assign(sa,b)} rel EXPR, where rel is an arithmetic relation and EXPR is some expression.

Related

Understanding unsolved metavariables and yellow highlighting in agda

In the agda docs, I read that when "some meta-variable other than the goals cannot be solved the code will be highlighted in yellow"
I'm trying to understand this in a somewhat degenerate case.
If I define a regular product type then a stupid program works fine.
data _==_ {l}{X : Set l}(x : X) : X -> Set where
refl : x == x
data prod (A B : Set) : Set where
_,,_ : A → B → prod A B
fst' : {A B : Set} → prod A B → A
fst' (x ,, x₁) = x
stupid : fst' (3 ,, 3) == 3
stupid = refl
However, if I use a product as a special case of a dependent product, I get the yellow highlighting for stupid''''. Specifically, the fst and and the second 3 are highlighed yellow. Why do all the other stupid*'s work except for stupid''''? Are there any general tips for debugging yellow highlighting errors in agda?
record Sg {l}(S : Set l)(T : S -> Set l) : Set l where
constructor _,_
field
fst : S
snd : T fst
open Sg public
_*_ : forall {l} -> Set l -> Set l -> Set l
S * T = Sg S \ _ -> T
infixr 40 _,_
infixr 20 _*_
threethree : Nat * Nat
threethree = 3 , 3
three : Nat
three = fst threethree
stupid'' : three == 3
stupid'' = refl
stupid''' : fst (threethree) == 3
stupid''' = refl
--here's the yellow highlighting
stupid'''' : fst (3 , 3) == 3
stupid'''' = refl
--here's the yellow highlighting
stupid'''' : fst (3 , 3) == 3
stupid'''' = refl
This is because Agda can't infer the type of (3 , 3) to supply it to fst.
"But that's just Nat * Nat!"
Not necessarily, it can be
Sg Nat \n -> if n == 3 then Nat else Bool
or any other weird type that gives Nat as a type of the second element whenever the first element is 3 and does something completely different in all other cases.
And Agda's unification machinery always either finds a unique solution or gives up.
You've asked Agda to solve the following unification problem:
_T 3 =?= Nat
and clearly there are way too many different _Ts that return Nat when the argument is 3.
Why do all the other stupid*'s work except for stupid''''
Because in all the other ones there's no ambiguity:
in stupid the type of the second element does not depend on the first element (due to the definition of prod)
in other cases you explicitly specify the type of the argument (via a standalone declaration)

Prolog: Splitting a number into a sequence of increasing integers

After doing some Prolog in uni and doing some exercises I decided to go along somewhat further although I got to admit I don't understand recursion that well, I get the concept and idea but how to code it, is still a question for me. So that's why I was curious if anyone knows how to help tackle this problem.
The idea is given a number e.g. 45, check whether it is possible to make a list starting with 1 going n+1 into the list and if the sum of the list is the same as the given number.
So for 45, [1,2,3,4,5,6,7,8,9] would be correct.
So far I tried looking at the [sum_list/2][1] implemented in Prolog itself but that only checks whether a list is the same as the number it follows.
So given a predicate lijstSom(L,S) (dutch for listSum), given
?- lijstSom(L, 45)
L = [1,2,3,4,5,6,7,8,9];
False
My Idea was something along the line of for example if S = 45, doing steps of the numbers (increasing by 1) and subtracting it of S, if 0 is the remainder, return the list, else return false.
But for that you need counters and I find it rather hard to grasp that in recursion.
EDIT:
Steps in recursion.
Base case empty list, 0 (counter nr, that is minus S), 45 (S, the remainder)
[1], 1, 44
[1,2], 2, 42
[1,2,3], 3, 39
I'm not sure how to read the example
?- lijstSom(L, 45)
L = [1,2,3,4,5,6,7,8,9],
False
...but think of the predicate lijstSom(List, Sum) as relating certain lists of integers to their sum, as opposed to computing the sum of lists of integers. Why "certain lists"? Because we have the constraint that the integers in the list of integers must be monotonically increasing in increments of 1, starting from 1.
You can thus ask the Prolog Processor the following:
"Say something about the relationship between the first argument of lijstSom/2 and the second argument lijstSom/2 (assuming the first is a list of monotonically increasing integers, and the second an integer):
lijstSom([1,2,3], Sum)
... should return true (because yes, there is at least one solution) and give Sum = 6 (because it constructs the solution, too ... we are some corner of Construtivism here.
lijstSom(L, 6)
... should return true (because yes, there is at least one solution) and give the solution [1,2,3].
lijstSom([1,2,3], 6)
... should return true (because yes, [1,2,3] has a sum 6); no further information is needed.
lijstSom(L, S)
... should an infinite series of true and pairs of solution ("generate the solutions").
L = [1], S = 1;
L = [1,2], S = 3;
L = [1,2,3], S = 6;
...
lijstSom([1,2,3], 7)
...should return false ("fail") because 7 is not in a relation lijstSom with [1,2,3] as 7 =/= 1+2+3.
One might even want things to have Prolog Processor say something interesting about:
lijstSom([1,2,X], 6)
X = 3
or even
lijstSom([1,2,X], S)
X = 3
S = 6
In fact, lijstSom/2 as near to mathematically magical as physically possible, which is to say:
Have unrestricted access to the full table of list<->sum relationships floating somewhere in Platonic Math Space.
Be able to find the correct entry in seriously less than infinite number of steps.
And output it.
Of course we are restricted to polynomial algorithms of low exponent and finite number of dstinguishable symbols for eminently practical reasons. Sucks!
So, first define lijstSom(L,S) using an inductive definition:
lijstSom([a list with final value N],S) ... is true if ... lijstSom([a list],S-N and
lijstSom([],0) because the empty list has sum 0.
This is nice because it gives the recipe to reduce a list of arbitrary length down to a list of size 0 eventually while keeping full knowledge its sum!
Prolog is not good at working with the tail of lists, but good with working with the head, so we cheat & change our definition of lijstSom/2 to state that the list is given in reverse order:
lijstSom([3,2,1], 6)
Now some code.
#= is the "constain to be equal" operator from library(clpfd). To employ it, we need to issue use_module(library(clpfd)). command first.
lijstSom([],0).
lijstSom([K|Rest],N) :- lijstSom([Rest],T), T+K #= N.
The above follows the mathematical desiderate of lijstSom and allows the Prolog Processor to perform its computation: in the second clause, it can compute the values for a list of size A from the values of a list of size A-1, "falling down" the staircase of always decreasing list length until it reaches the terminating case of lijstSom([],0)..
But we haven't said anything about the monotonically decreasing-by-1 list.
Let's be more precise:
lijstSom([],0) :- !.
lijstSom([1],1) :- ! .
lijstSom([K,V|Rest],N) :- K #= V+1, T+K #= N, lijstSom([V|Rest],T).
Better!
(We have also added '!' to tell the Prolog Processor to not look for alternate solutions past this point, because we know more about the algorithm than it will ever do. Additionally, the 3rd line works, but only because I got it right after running the tests below and having them pass.)
If the checks fail, the Prolog Processor will says "false" - no solution for your input. This is exactly what we want.
But does it work? How far can we go in the "mathematic-ness" of this eminently physical machine?
Load library(clpfd) for constraints and use library(plunit) for unit tests:
Put this into a file x.pl that you can load with [x] alias consult('x') or reload with make on the Prolog REPL:
:- use_module(library(clpfd)).
lijstSom([],0) :-
format("Hit case ([],0)\n"),!.
lijstSom([1],1) :-
format("Hit case ([1],1)\n"),!.
lijstSom([K,V|Rest],N) :-
format("Called with K=~w, V=~w, Rest=~w, N=~w\n", [K,V,Rest,N]),
K #= V+1,
T+K #= N,
T #> 0, V #> 0, % needed to avoid infinite descent
lijstSom([V|Rest],T).
:- begin_tests(listsom).
test("0 verify") :- lijstSom([],0).
test("1 verify") :- lijstSom([1],1).
test("3 verify") :- lijstSom([2,1],3).
test("6 verify") :- lijstSom([3,2,1],6).
test("0 construct") :- lijstSom(L,0) , L = [].
test("1 construct") :- lijstSom(L,1) , L = [1].
test("3 construct") :- lijstSom(L,3) , L = [2,1].
test("6 construct") :- lijstSom(L,6) , L = [3,2,1].
test("0 sum") :- lijstSom([],S) , S = 0.
test("1 sum") :- lijstSom([1],S) , S = 1.
test("3 sum") :- lijstSom([2,1],S) , S = 3.
test("6 sum") :- lijstSom([3,2,1],S) , S = 6.
test("1 partial") :- lijstSom([X],1) , X = 1.
test("3 partial") :- lijstSom([X,1],3) , X = 2.
test("6 partial") :- lijstSom([X,2,1],6) , X = 3.
test("1 extreme partial") :- lijstSom([X],S) , X = 1, S = 1.
test("3 extreme partial") :- lijstSom([X,1],S) , X = 2, S = 3.
test("6 extreme partial") :- lijstSom([X,2,1],S) , X = 3, S = 6.
test("6 partial list") :- lijstSom([X|L],6) , X = 3, L = [2,1].
% Important to test the NOPES
test("bad list", fail) :- lijstSom([3,1],_).
test("bad sum", fail) :- lijstSom([3,2,1],5).
test("reversed list", fail) :- lijstSom([1,2,3],6).
test("infinite descent from 2", fail) :- lijstSom(_,2).
test("infinite descent from 9", fail) :- lijstSom(_,9).
:- end_tests(listsom).
Then
?- run_tests(listsom).
% PL-Unit: listsom ...................... done
% All 22 tests passed
What would Dijkstra say? Yeah, he would probably bitch about something.

Swapping Variables by pattern matching?

Assume you have 2 Integer Variables a and b
How would you swap them only if a > b by using a match expression?
If a <= b do not swap the ints.
In an imperative language:
if (a > b){
int temp=a;
a=b;
b=temp;
}
Doing the same in ocaml seems surprisingly hard.
I tried
let swap a b =
match a,b with
| a,b when a > b -> b,a
| a,b when a <= b -> a,b
I am trying to do this because in the following function call, I want to make sure that x is the bigger of the two variables.
One easy way :
let swap a b =
if (a>b) then (b,a)
else (a,b)
But this is not equivalent to the C code, your C code is swapping the value of the variable - this is how imperative language are doing.
In Ocaml, there is no side-effect (except if you use reference to some int). This swap function will return a tuple whose members are always ordered (the first member will be always smaller than the second order).
Without state, you cannot "swap" the values of the variables since the variables are immutable. Your best bet is to use a tuple and introduce new variables in the scope. Example:
let diff a b =
let (min, max) = if a <= b then (a, b) else (b, a)
in max - min
You can of course use the same identifiers and shadow the original variables:
let diff a b =
let (a, b) = if a <= b then (a, b) else (b, a)
in b - a
It doesn't really help with readability though.
Just for reference, if you'd like to swap the values in two refs, it would look like the following:
let swap a_ref b_ref =
let a, b = !a_ref, !b_ref in
a_ref := b;
b_ref := a
;;
which has the type val swap : 'a ref -> 'a ref -> unit.

Is it possible to overload functions in Scilab?

I would like to know how to overload a function in scilab. It doesn't seem to be as simple as in C++. For example,
function [A1,B1,np1]=pivota_parcial(A,B,n,k,np)
.......//this is just an example// the code doesn't really matter
endfunction
//has less input/output variables//operates differently
function [A1,np1]=pivota_parcial(A,n,k,np)
.......//this is just an example// the code doesn't really matter
endfunction
thanks
Beginner in scilab ....
You can accomplish something like that by combining varargin, varargout and argn() when you implement your function. Take a look at the following example:
function varargout = pivota_parcial(varargin)
[lhs,rhs] = argn();
//first check number of inputs or outputs
//lhs: left-hand side (number of outputs)
//rhs: right-hand side (number of inputs)
if rhs == 4 then
A = varargin(1); B = 0;
n = varargin(2); k = varargin(3);
np = varargin(4);
elseif rhs == 5 then
A = varargin(1); B = varargin(2);
n = varargin(3); k = varargin(4);
np = varargin(5);
else
error("Input error message");
end
//computation goes on and it may depend on (rhs) and (lhs)
//for the sake of running this code, let's just do:
A1 = A;
B1 = B;
np1 = n;
//output
varargout = list(A1,B1,np1);
endfunction
First, you use argn() to check how many arguments are passed to the function. Then, you rename them the way you need, doing A = varargin(1) and so on. Notice that B, which is not an input in the case of 4 inputs, is now set to a constant. Maybe you actually need a value for it anyways, maybe not.
After everything is said and done, you need to set your output, and here comes the part in which using only varargout may not satisfy your need. If you use the last line the way it is, varargout = list(A1,B1,np1), you can actually call the function with 0 and up to 3 outputs, but they will be provided in the same sequence as they appear in the list(), like this:
pivota_parcial(A,B,n,k,np);: will run and the first output A1 will be delivered, but it won't be stored in any variable.
[x] = pivota_parcial(A,B,n,k,np);: x will be A1.
[x,y] = pivota_parcial(A,B,n,k,np);: x will be A1 and y will be B1.
[x,y,z] = pivota_parcial(A,B,n,k,np);: x will be A1, y will be B1, z will be np1.
If you specifically need to change the order of the output, you'll need to do the same thing you did with your inputs: check the number of outputs and use that to define varargout for each case. Basically, you'll have to change the last line by something like the following:
if lhs == 2 then
varargout = list(A1,np1);
elseif lhs == 3 then
varargout = list(A1,B1,np1);
else
error("Output error message");
end
Note that even by doing this, the ability to call this functions with 0 and up to 2 or 3 outputs is retained.

Division in prolog

I'm trying to define the division in prolog using the remainder theorem and the well-ordering principle.
I've got thus far:
less(0, s(0)).
less(0, s(B)) :- less(0, B).
less(s(A), s(s(B))) :- less(A, s(B)).
add(A,0,A) :- nat(A).
add(A,s(B),s(C)) :- add(A,B,C). % add(A,B+1,C+1) = add(A,B,C)
add2(A,0,A).
add2(A,s(B),s(C)) :- add2(A,B,C). % add(A,B+1,C+1) = add(A,B,C)
times(A,0,0).
times(A,s(B),X) :- times(A,B,X1),
add(A,X1,X).
eq(0,0).
eq(s(A), s(B)) :- eq(A, B).
% A / B = Q (R) => A = B * Q + R
div(A, B, Q, R) :- less(R, B), eq(A, add(times(Q, R), R)).
But the definition of div is somehow wrong. Could someone please give me a hint?
PS: I shouldn't be using eq, but I couldn't get is or = to work.
In SWI-Prolog, you can try ?- gtrace, your_goal. to use the graphical tracer and see what goes wrong. Instead of eq(A, add(times(Q, R), R)), you should write for example: times(Q, R, T), add(T, R, A), since you want to use the "times/3" and "add/3" predicates, instead of just calling the "eq/2" predicate with a compound term consisting of "add/2" and "times/2" as its second argument. There are other problems with the code as well, for example, the definition of nat/1 is missing, but I hope this helps somewhat.

Resources