Howto import operators in swi-prolog? - module

I have the following file:
:- use_module(library(clpfd)).
isPowTwo(N) :- N #> 0, N #= 2^_.
Everything works fine:
?- [importTest].
% library(pairs) compiled into pairs 0.00 sec, 22 clauses
% library(lists) compiled into lists 0.01 sec, 122 clauses
% library(occurs) compiled into occurs 0.00 sec, 14 clauses
% library(apply_macros) compiled into apply_macros 0.01 sec, 168 clauses
% library(assoc) compiled into assoc 0.01 sec, 103 clauses
% library(clpfd) compiled into clpfd 0.15 sec, 2,808 clauses
% importTest compiled 0.16 sec, 2,813 clauses
true.
Now I want to import just the two used operators:
:- use_module(library(clpfd), [(#>)/2, (#=)/2]).
isPowTwo(N) :- N #> 0, N #= 2^_.
And it does not work:
?- [importTest].
% library(pairs) compiled into pairs 0.00 sec, 22 clauses
% library(lists) compiled into lists 0.01 sec, 122 clauses
% library(occurs) compiled into occurs 0.00 sec, 14 clauses
% library(apply_macros) compiled into apply_macros 0.01 sec, 168 clauses
% library(assoc) compiled into assoc 0.01 sec, 103 clauses
% library(clpfd) compiled into clpfd 0.16 sec, 2,808 clauses
ERROR: .../importTest.pl:3:17: Syntax error: Operator expected
% importTest compiled 0.16 sec, 2,812 clauses
true.
?- isPowTwo(1).
ERROR: toplevel: Undefined procedure: isPowTwo/1 (DWIM could not correct goal)
Leaving the parentheses around #> and #= makes no difference.


You have a syntax error in your use_module/2 directive (hence the Syntax error: Operator expected error messages). You can correct it by writing:
:- use_module(library(clpfd), [(#>)/2, (#=)/2]).
But you will also need to import the corresponding operators for use in the definition of your isPowTwo/1 predicate:
:- use_module(library(clpfd), [(#>)/2, (#=)/2, op(700,xfx,(#>)), op(700,xfx,(#=))]).

Related

What is more costly for a computer to compute (2*2) or (0.02*0.02)?

The title says it.
I was wondering if normalization has any effect on computing.
Does normalization effect computing?

It is costlier to compute 0.02 * 0.02 compared to 2 * 2 has 2 * 2 is a single math operation where only one multiplication is involved.
Floating point number are stored has 2*10^-2 format(scientific notation). Therefore, two operations are involved here,
2 * 2
(-2) + (-2)
Thus, the answer is computed as 4 * 10^(-4) or 0.0004.
Thus, 0.02 * 0.02 is costlier compared to 2*2.

GAMS - Economic Dispatch - QCP and NLP

I have this code:
If I use NLP i get the results, but using QCP as it was asked to me, I can not get results
anyone can help me finding the reason?
code:
sets g generators / P1*P5 /
properties generator properties / a,b,c,max,min /
cc(properties) cost categories / a,b,c /
table data(g,properties) generator cost characteristics and limits
a b c max min
P1 0.19 58.3 1800 155 35
P2 0.13 39.3 3250 195 60
P3 0.08 11.5 4600 165 95
P4 0.07 42.6 5100 305 170
P5 0.14 8.9 3850 280 130
parameter exp(cc) exponent for cost function / a 2, b 1, c 0 /;
scalar demand total power demand in MW / 730 / ;
variables
p(g) power generation level in MW
cost total generation cost - the objective function ;
positive variables p;
p.up(g) = data(g,"max") ;
p.lo(g) = data(g,"min") ;
equations
Q_Eq1 total cost calculation
Q_Eq2 constraint - total generation must equal demand ;
Q_Eq1 .. cost =e= sum((g,cc), data(g,cc)*power(p(g),exp(cc)));
Q_Eq2 .. sum(g,p(g)) =g= demand ;
model problem /all/ ;
solve problem using QCP minimizing cost ;

Seems as if the function "power" is treated as nonlinear in general without analyzing the value of "exp", so that it is not allowed for a QCP. You could reformulate Q_Eq1 like this to make it work:
Q_Eq1 .. cost =e= sum((g,cc), data(g,cc)*(1 $(exp(cc)=0) +
p(g) $(exp(cc)=1) +
sqr(p(g))$(exp(cc)=2)));
Best,
Lutz

Why does CPlex solve this mixed integer linear program so incredibly fast?

I am working on an optimization problem where I want to find resource-activity assignment based on skill restrictions (not all resources have all skills for the demands d), resource restrictions (resources have a limited presence p) and an assignment restriction l limiting the number of resources assigned to an activity. I want to maximize the sum of weights w of all selected activities. The model is depicted here:
Now I fed this into CPlex and it solves gigantic instances in a very short amount of time as long as I allow heuristics (1000 activities, 50 resources, 5 skills within about 10 sec), even though there is a huge possible number of selected issues AND a huge number of possible assignments for each activity.
Why is this problem so easy for CPlex? Is there some kind of easily solvable underlying problem that I am missing?
edit: typical output of one of my solver runs:
Tried aggregator 1 time.
MIP Presolve eliminated 3051 rows and 64954 columns.
MIP Presolve modified 49950 coefficients.
Reduced MIP has 52001 rows, 236046 columns, and 662190 nonzeros.
Reduced MIP has 47952 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.61 sec. (276.60 ticks)
Probing time = 0.38 sec. (12.12 ticks)
Tried aggregator 1 time.
MIP Presolve eliminated 1323 rows and 62181 columns.
MIP Presolve modified 3366 coefficients.
Reduced MIP has 50678 rows, 173865 columns, and 474324 nonzeros.
Reduced MIP has 47952 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.78 sec. (334.49 ticks)
Probing time = 0.26 sec. (9.19 ticks)
Tried aggregator 1 time.
Reduced MIP has 50678 rows, 173865 columns, and 474324 nonzeros.
Reduced MIP has 47952 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.49 sec. (220.07 ticks)
Probing time = 0.36 sec. (10.46 ticks)
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 8 threads.
Root relaxation solution time = 2.86 sec. (1101.00 ticks)
Nodes Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap
* 0+ 0 7.0000 5631.0000 3104 ---
0 0 2265.4000 2 7.0000 2265.4000 3104 ---
* 0+ 0 2265.0000 2265.4000 3107 0.02%
* 0 0 integral 0 2265.0000 2265.4000 3107 0.02%
Elapsed time = 7.59 sec. (2779.25 ticks, tree = 0.00 MB, solutions = 2)
Cover cuts applied: 1
Root node processing (before b&c):
Real time = 7.61 sec. (2792.47 ticks)
Parallel b&c, 8 threads:
Real time = 0.00 sec. (0.00 ticks)
Sync time (average) = 0.00 sec.
Wait time (average) = 0.00 sec.
------------
Total (root+branch&cut) = 7.61 sec. (2792.47 ticks)

I think that's because the form of your model is relatively simple, such as the objective function, and the model scale is rather small. You can test CPLEX with more complicated examples. I used to solve a MIP model with more than 800 thousand constraints and 300 thousand variables.

Incorrect Mod result in VB.NET

I'm getting incorrect Mod operator result in VB.NET. I verified result with calculator, It gives correct result.
E.g In VB.NET 1.3 Mod 0.05 = 0.049999999999999975 whereas in Calculator it shows 0

It's round up error:
1.30000000000001 Mod 0.05 == 0.00000000000001
1.2999999 Mod 0.05 == 0.0499998999999999
usually, round up errors are little (if any) nuisance, put at / near points of discontinuity small errors lead to big difference at the result (0.05 in this case).
Amendment: change the initial double to either int (long)
130 Mod 5 == 0
or decimal:
1.3M Mod 0.05M == 0

Prolog Does the order of recursion matter?

I have a question about the difference between two solutions to a problem. The problem asks to transform a list to a truncated list like so:
?- reduce([a,a,a,b,b,c,c,b,b,d,d],Z).
Z = [a,b,c,b,d].
This first solution needs an extra step that reverses the list:
reduce([X|Xs],Z) :-
reduce(X,Xs,Y,[X]),
reverse(Y,Z).
reduce(X,[L|Ls],Y,List) :-
( X=L
-> reduce(X,Ls,Y,List)
; reduce(L,Ls,Y,[L|List])
).
reduce(_,[],Y,Y).
The second solution does not require reverse/2:
reduced([X|Xs],Result) :-
reduced(Xs,List),
List=[A|_],
( A=X
-> Result=List
; Result=[X|List]
),
!.
reduced(Result,Result).
What are the optimization considerations when performing recursion before or after a series of statements? Does the order of the conditions matters? My inclination is to think that doing all the recursion upfront is the way to go, especially because building the list backwards is necessary here.

When you optimize anything, make sure to measure first! (most of us tend to forget this....)
When you optimize Prolog, look out for the following:
Tail recursion tends to do better (so there goes your "before or after series of statements" question);
Avoid creating choice points you don't need (this depends on the Prolog implementation)
Use an optimal algorithm (as in, don't traverse a list twice if you don't have to).
A solution that is "optimized" for a more or less standard Prolog implementation will look maybe a bit different. I will name it list_uniq (in analogy to the command-line uniq tool):
list_uniq([], []). % Base case
list_uniq([H|T], U) :-
list_uniq_1(T, H, U). % Helper predicate
list_uniq_1([], X, [X]).
list_uniq_1([H|T], X, U) :-
( H == X
-> list_uniq_1(T, X, U)
; [X|U1] = U,
list_uniq_1(T, H, U1)
).
It is different from the reduce0/2 by #CapelliC because it uses lagging to avoid the inherent non-determinism of [X|Xs] and [X,X|Xs] in the first argument.
Now to the claim that it is "optimized":
It traverses the list exactly once (no need for reversing)
It it tail-recursive
It does not create and discard choice points
You will get the same 12 inferences as #CapelliC, and if you then use a somewhat longer list, you will start to see differences:
?- length(As, 100000), maplist(=(a), As),
length(Bs, 100000), maplist(=(b), Bs),
length(Cs, 100000), maplist(=(c), Cs),
append([As, Bs, Cs, As, Cs, Bs], L),
time(list_uniq(L, U)).
% 600,006 inferences, 0.057 CPU in 0.057 seconds (100% CPU, 10499893 Lips)
As = [a, a, a, a, a, a, a, a, a|...],
Bs = [b, b, b, b, b, b, b, b, b|...],
Cs = [c, c, c, c, c, c, c, c, c|...],
L = [a, a, a, a, a, a, a, a, a|...],
U = [a, b, c, a, c, b].
The same query with reduce0, reduce1, reduce2 from #CapelliC's answer:
% reduce0(L, U)
% 600,001 inferences, 0.125 CPU in 0.125 seconds (100% CPU, 4813955 Lips)
% reduce1(L, U)
% 1,200,012 inferences, 0.393 CPU in 0.394 seconds (100% CPU, 3050034 Lips)
% reduce2(L, U)
% 2,400,004 inferences, 0.859 CPU in 0.861 seconds (100% CPU, 2792792 Lips)
So, creating and discarding choice points with cuts (!) has a price, too.
However, list_uniq/2, as it stands, can be wrong for queries where the first argument is not ground:
?- list_uniq([a,B], [a,b]).
B = b. % OK
?- list_uniq([a,A], [a]).
false. % WRONG!
reduce0/2 and reduce1/2 can be wrong, too:
?- reduce0([a,B], [a,b]).
false.
?- reduce1([a,B], [a,b]).
false.
As for reduce2/2, I am not sure about this one:
?- reduce2([a,A], [a,a]).
A = a.
Instead, using the definition of if_/3 from this answer:
list_uniq_d([], []). % Base case
list_uniq_d([H|T], U) :-
list_uniq_d_1(T, H, U). % Helper predicate
list_uniq_d_1([], X, [X]).
list_uniq_d_1([H|T], X, U) :-
if_(H = X,
list_uniq_d_1(T, H, U),
( [X|U1] = U,
list_uniq_d_1(T, H, U1)
)
).
With it:
?- list_uniq_d([a,a,a,b], U).
U = [a, b].
?- list_uniq_d([a,a,a,b,b], U).
U = [a, b].
?- list_uniq_d([a,A], U).
A = a,
U = [a] ;
U = [a, A],
dif(A, a).
?- list_uniq_d([a,A], [a]).
A = a ;
false. % Dangling choice point
?- list_uniq_d([a,A], [a,a]).
false.
?- list_uniq_d([a,B], [a,b]).
B = b.
?- list_uniq_d([a,A], [a,a]).
false.
It takes longer, but the predicate seems to be correct.
With the same query as used for the other timings:
% 3,000,007 inferences, 1.140 CPU in 1.141 seconds (100% CPU, 2631644 Lips)

profiling seems the easier way to answer to efficiency questions:
% my own
reduce0([], []).
reduce0([X,X|Xs], Ys) :- !, reduce0([X|Xs], Ys).
reduce0([X|Xs], [X|Ys]) :- reduce0(Xs, Ys).
% your first
reduce1([X|Xs],Z) :- reduce1(X,Xs,Y,[X]), reverse(Y,Z).
reduce1(X,[L|Ls],Y,List) :-
X=L -> reduce1(X,Ls,Y,List);
reduce1(L,Ls,Y,[L|List]).
reduce1(_,[],Y,Y).
% your second
reduce2([X|Xs],Result) :-
reduce2(Xs,List),
List=[A|_],
(A=X -> Result=List;
Result=[X|List]),!.
reduce2(Result,Result).
SWI-Prolog offers time/1:
4 ?- time(reduce0([a,a,a,b,b,c,c,b,b,d,d],Z)).
% 12 inferences, 0.000 CPU in 0.000 seconds (84% CPU, 340416 Lips)
Z = [a, b, c, b, d].
5 ?- time(reduce1([a,a,a,b,b,c,c,b,b,d,d],Z)).
% 19 inferences, 0.000 CPU in 0.000 seconds (90% CPU, 283113 Lips)
Z = [a, b, c, b, d] ;
% 5 inferences, 0.000 CPU in 0.000 seconds (89% CPU, 102948 Lips)
false.
6 ?- time(reduce2([a,a,a,b,b,c,c,b,b,d,d],Z)).
% 12 inferences, 0.000 CPU in 0.000 seconds (83% CPU, 337316 Lips)
Z = [a, b, c, b, d].
your second predicate performs like mine, while the first one seems to leave a choice point...
Order of conditions it's of primary importance, given the resolution strategy Prolog implements. In naive implementations, like mine IL, tail recursion optimization was recognized only when the recursive call was the last, and preceded by a cut. Just to be sure it's deterministic...

This answer is a direct follow-up to #Boris's answer.
To estimate the runtime we can expect once if_/3 is compiled,
I made list_uniq_e/2 which is just like #Boris's list_uniq_d/2 with the if_/3 compiled manually.
list_uniq_e([], []). % Base case
list_uniq_e([H|T], U) :-
list_uniq_e_1(T, H, U). % Helper predicate
list_uniq_e_1([], X, [X]).
list_uniq_e_1([H|T], X, U) :-
=(H,X,Truth),
list_uniq_e_2(Truth,H,T,X,U).
list_uniq_e_2(true ,H,T,_, U ) :- list_uniq_e_1(T,H,U).
list_uniq_e_2(false,H,T,X,[X|U]) :- list_uniq_e_1(T,H,U).
Let's compare the runtime (SWI Prolog 7.3.1, Intel Core i7-4700MQ 2.4GHz)!
First up, list_uniq_d/2:
% 3,000,007 inferences, 0.623 CPU in 0.623 seconds (100% CPU, 4813150 Lips)
Next up, list_uniq_e/2:
% 2,400,003 inferences, 0.132 CPU in 0.132 seconds (100% CPU, 18154530 Lips)
For the sake of completeness reduce0/2, reduce1/2, and reduce2/2:
% 600,002 inferences, 0.079 CPU in 0.079 seconds (100% CPU, 7564981 Lips)
% 600,070 inferences, 0.141 CPU in 0.141 seconds (100% CPU, 4266842 Lips)
% 600,001 inferences, 0.475 CPU in 0.475 seconds (100% CPU, 1262018 Lips)
Not bad! And... this is not the end of the line---as far as optimizing if_/3 is concerned:)

Hoping this is an even better follow-up to #Boris's answer than my last try!
First, here's #Boris's code again (100% original):
list_uniq_d([], []). % Base case
list_uniq_d([H|T], U) :-
list_uniq_d_1(T, H, U). % Helper predicate
list_uniq_d_1([], X, [X]).
list_uniq_d_1([H|T], X, U) :-
if_(H = X,
list_uniq_d_1(T, H, U),
( [X|U1] = U,
list_uniq_d_1(T, H, U1)
)
).
Plus some more code for benchmarking:
bench(P_2) :-
length(As, 100000), maplist(=(a), As),
length(Bs, 100000), maplist(=(b), Bs),
length(Cs, 100000), maplist(=(c), Cs),
append([As, Bs, Cs, As, Cs, Bs], L),
time(call(P_2,L,_)).
Now, let's introduce module re_if:
:- module(re_if, [if_/3, (=)/3, expand_if_goals/0]).
:- dynamic expand_if_goals/0.
trusted_truth(_=_). % we need not check truth values returned by (=)/3
=(X, Y, R) :- X == Y, !, R = true.
=(X, Y, R) :- ?=(X, Y), !, R = false. % syntactically different
=(X, Y, R) :- X \= Y, !, R = false. % semantically different
=(X, Y, R) :- R == true, !, X = Y.
=(X, X, true).
=(X, Y, false) :- dif(X, Y).
:- meta_predicate if_(1,0,0).
if_(C_1,Then_0,Else_0) :-
call(C_1,Truth),
functor(Truth,_,0), % safety check
( Truth == true -> Then_0
; Truth == false , Else_0
).
:- multifile system:goal_expansion/2.
system:goal_expansion(if_(C_1,Then_0,Else_0), IF) :-
expand_if_goals,
callable(C_1), % nonvar && (atom || compound)
!,
C_1 =.. Ps0,
append(Ps0,[T],Ps1),
C_0 =.. Ps1,
( trusted_truth(C_1)
-> IF = (C_0, ( T == true -> Then_0 ; Else_0))
; IF = (C_0,functor(T,_,0),( T == true -> Then_0 ; T == false, Else_0))
).
And now ... *drumroll* ... lo and behold:)
$ swipl
Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 7.3.3-18-gc341872)
Copyright (c) 1990-2015 University of Amsterdam, VU Amsterdam
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
Please visit http://www.swi-prolog.org for details.
For help, use ?- help(Topic). or ?- apropos(Word).
?- compile(re_if), compile(list_uniq).
true.
?- bench(list_uniq_d).
% 2,400,010 inferences, 0.865 CPU in 0.865 seconds (100% CPU, 2775147 Lips)
true.
?- assert(re_if:expand_if_goals), compile(list_uniq).
true.
?- bench(list_uniq_d).
% 1,200,005 inferences, 0.215 CPU in 0.215 seconds (100% CPU, 5591612 Lips)
true.