Here we have two predicates
len -> return the length of a list.
processRel -> calls len.
len([],0).
len([_|T], R):-
len(T,X),
R is X+1.
processRel([H|Q],X):-
len(H,X).
why it doesn't unify?
it returns this:
?- processRel([1,2,3,4],X).
false.
Instead of (my expectation):
X = 4.
The predicates "len" works, I've already tested it, but I don't understand why if put that predicates in another, it works like that. thank you!
You should make it
processRel(L,X):-
len(L,X).
Right now, it is
processRel([H|Q],X):-
len(H,X).
Inserting [1,2,3,4] means we get
processRel([1,2,3,4],X):-
len(1,X).
So it unifies to len(1,X). Which isn't defined because 1 is not a list.
I have a large numbers of facts that are already in my file (position(M,P)), M is the name and P is the position of the player , I am asked to do a player_list(L,N), L is the list of players and N is the size of this list. I did it and it works the problem is that it gives the list without the names it gives me numbers and not names
player_list([H|T],N):- L = [H|T],
position(H,P),
\+ member(H,L),
append(L,H),
player_list(T,N).
what I get is:
?- player_list(X,4).
X = [_9176, _9182, _9188, _9194] .
so what should I do ?
You could use an additional list as an argument to keep track of the players you already have. This list is empty at the beginning, so the calling predicate calls the predicate describing the actual relation with [] as an additional argument:
player_list(PLs,L) :-
pl_l_(PLs,L,[]). % <- actual relation
The definition you posted is missing a base case, that is, if you already have the desired amount of players, you can stop adding others. In this case the number of players to add is zero otherwise it is greater than zero. You also have to describe that the head of the list (PL) is a player (whose position you don't care about, so the variable is preceded by an underscore (_P), otherwise the goal is just like in your code) and is not in the accumulator yet (as opposed to your code, where you check if PL is not in L) but in the recursive call it is in the accumulator. You can achieve the latter by having [PL|Acc0] in the recursive goal, so you don't need append/2. Putting all this together, your code might look something like this:
pl_l_([],0,_). % base case
pl_l_([PL|PLs],L1,Acc0) :-
L1 > 0, % number of players yet to add
L0 is L1-1, % new number of players to add
position(PL,_P), % PL is a player and
\+ member(PL,Acc0), % not in the accumulator yet
pl_l_(PLs,L0,[PL|Acc0]). % the relation holds for PLs, L0 and [PL|Acc0] as well
With respect to your comment, I assume that your code contains the following four facts:
position(zlatan,center).
position(rooney,forward).
position(ronaldo,forward).
position(messi,forward).
Then your example query yields the desired results:
?- player_list(X,4).
X = [zlatan,rooney,ronaldo,messi] ? ;
X = [zlatan,rooney,messi,ronaldo] ? ;
...
If you intend to use the predicate the other way around as well, I suggest the use of CLP(FD). To see why, consider the most general query:
?- player_list(X,Y).
X = [],
Y = 0 ? ;
ERROR at clause 2 of user:pl_l_/3 !!
INSTANTIATION ERROR- =:=/2: expected bound value
You get this error because >/2 expects both arguments to be ground. You can modify the predicate pl_l_/3 to use CLP(FD) like so:
:- use_module(library(clpfd)).
pl_l_([],0,_).
pl_l_([PL|PLs],L1,Acc0) :-
L1 #> 0, % <- new
L0 #= L1-1, % <- new
position(PL,_P),
\+ member(PL,Acc0),
pl_l_(PLs,L0,[PL|Acc0]).
With these modifications the predicate is more versatile:
?- player_list([zlatan,messi,ronaldo],Y).
Y = 3
?- player_list(X,Y).
X = [],
Y = 0 ? ;
X = [zlatan],
Y = 1 ? ;
X = [zlatan,rooney],
Y = 2 ?
...
I'm having a bit of trouble with something. I've wrote a function that returns the number of occurrences of an element in a list. Here is the code:
occurencesHelp(X,[],N,N).
occurencesHelp(X,[X|T],N,Y) :-
N1 is N+1,
occurencesHelp(X,T,N1,Y).
occurencesHelp(X,[H|T],N,Y) :-
occurencesHelp(X,T,N,Y).
occurences(X,List,N) :-
occurencesHelp(X,List,0,N).
This works fine, the first answer I get is:
N = 5 ?
but then there are multiple answers such as:
N = 4 ? ;
N = 4 ? ;
N = 3 ? ;
N = 4 ? ;
N = 3 ? ;
and so on. I've tried tracing through to see if I can see why this is the case but can't figure it out. I think using a cut would help me, but we have been specifically told not to use cut, so that isn't an option. Any help would be appreciated.
Thanks.
When I load your code in SWI-Prolog, I get the following warnings:
Warning: /home/isabelle/occ.pl:1:
Singleton variables: [X]
Warning: /home/isabelle/occ.pl:7:
Singleton variables: [H]
These warnings are important. Singleton variables are very often a sign that you have made a serious logical error. In your case, let's look at line 7. It's in this clause:
occurencesHelp(X,[H|T],N,Y) :-
occurencesHelp(X,T,N,Y).
Prolog tells us that H is a singleton variable. This means that it only occurs once in this clause, and this means that we forgot to put H in a relation with the other variables.
The previous clause says (procedurally): "if the head of the list is X, increment the counter". Conversely, this clause should say: "if the head of the list is not X, keep the counter unchanged". But it does not say that about the head of the list: In fact, it doesn't say anything about H (hence the warning).
So what you need to add is a goal expressing the fact that X and H should be unequal. Two ways to express this are X \= H and dif(X, H). In your case, the choice depends on what you have already learned in your course.
(The singleton warning for line 1 is benign in this case; you can just replace X by _X to tell Prolog that you explicitly want to ignore that variable.)
I'm new to Prolog and working through the exercises for Chapter 3 of Adventure In Prolog. Given the logicbase:
gizmo(a,1).
gizmo(b,3).
gizmo(a,2).
gizmo(d,5).
gizmo(c,3).
gizmo(a,3).
gizmo(c,4).
Why is it that
| ?- gizmo(X,X).
results in the following trace?
More specifically, why does it fail?
| ?- gizmo(X,X).
1 1 Call: gizmo(_279,_279) ? c
1 1 Fail: gizmo(_279,_279) ? c
(1 ms) no
{trace}
Since
gizmo(a,X)
and
gizmo (X,3)
,for example, both seem to act like wildcards and return every possible a and every possible 3 result respectively...
I thought that
gizmo(X,X)
would return every possible result for both sides (both the letters and numbers) but instead returns a fail, and no other result.
Would someone be willing to explain why it's a fail instead of returning all values from each side, keeping in mind I am a beginner?
Thanks in advance.
X is a variable but it's a unique one. gizmo(X,X). will return every possible value of X for which it is true. But that's the same value on the left and right side because it's the same variable (namely, X).
If you had a fact gizmo(z,z)., then gizmo(X,X). would correctly return X = z.
To get every possible pairs for which gizmo is true, you want to use gizmo(X,Y). or any other variables names as long as they are different.
Whats up?
I'm having some really weird problems with Prolog.
A recursive rule to replace an element in a list at a given index isn't always working.
My rule looks like this:
% Base rule - Stops when index is 1 and replaces the head with the element.
replaceAtIndex(1, _element, [_|_tail], [_element|_tail]).
% Recursive rule - Enter recursion for tail as long as index is larger than 1.
replaceAtIndex(_index, _element, [_head|_tail], [_head|_new_tail]):-
_index > 1,
_new_index is _index - 1,
replaceAtIndex(_new_index, _element, _tail, _new_tail).
When I use the debugger from within my program I see its always calling the second rule no matter what the index is, but when I execute the exact same command outside my program it works perfectly well. It reaches index 1 but calls the second rule, and does NOT backtrack and attempt the first rule and fails all the way back up...
The rule calling the replaceAtIndex looks like this:
level_replace_block_value(_x, _y, _value):-
current_level(_level_number, _width, _height, _blocks, _drawX, _drawY),
coordinates_to_index(_x, _y, _index),
_index_in_list is _index + 1, % the replaceAtIndex is not 0 terminated
replaceAtIndex(_index_in_list, _value, _blocks, _new_blocks),
retractall(current_level(_,_,_,_,_,_)),
assert(current_level(_level_number, _width, _height, _new_blocks, _drawX, _drawY),
graphics_update_block_value(_x, _y).
When I'm debugging its calling with index being 111.
When I'm replacing the _index_in_list with a constant 111 it works.
Anyone might have a clue why that happens?
Preserve logical-purity by using the builtin predicates same_length/2, length/2 and append/3!
replace_at(I,X,Xs0,Xs2) :-
same_length(Xs0,Xs2),
append(Prefix,[_|Xs1],Xs0),
length([_|Prefix],I),
append(Prefix,[X|Xs1],Xs2).
First, let's run the sample query that #magus used in a previous answer to this question:
?- replace_at(3,0,[1,2,3,4,5,6],Xs).
Xs = [1,2,0,4,5,6] ;
false.
Does it work when the list items are instantiated later?
?- replace_at(3,0,[A,B,C,D,E,F],Xs), A=1,B=2,C=3,D=4,E=5,F=6.
A = 1, B = 2, C = 3, D = 4, E = 5, F = 6, Xs = [1,2,0,4,5,6] ;
false.
Yes! What if the index isn't a concrete integer, but an unbound logical variable? Does that work?
?- replace_at(I,x,[_,_,_,_,_],Ys).
I = 1, Ys = [ x,_B,_C,_D,_E] ;
I = 2, Ys = [_A, x,_C,_D,_E] ;
I = 3, Ys = [_A,_B, x,_D,_E] ;
I = 4, Ys = [_A,_B,_C, x,_E] ;
I = 5, Ys = [_A,_B,_C,_D, x] ;
false.
It does! With monotone code, we get logically sound answers even with very general queries.
I suspect you misunderstand the direction in which backtracking will take place.
The first "base" rule will be tried first for any call to replaceAtIndex/4. If it fails, due to non-unifiability of the call with the "head" of the first rule, then the Prolog engine backtracks to the second rule. [Unification failure might result either from the first argument (index) differing from 1 or from the third argument not being a nonempty list.]
Backtracking never goes in the other direction. If the second rule is tried and fails, the call fails.
Of course things are complicated by the recursive definition. The success of applying the second rule entails a new call to replaceAtIndex/4, which as far as the Prolog engine is concerned must begin attempting to satisfy that goal by starting back at the first rule.
I'd suggest adding a cut to the first rule, since by construction the second rule will never succeed if the first rule does. But this is just an efficiency issue... why leave a choicepoint open that will never produce any further solutions?
replaceAtIndex(1, _element, [_|_tail], [_element|_tail]) :- !.
Added: I confirmed that your code works in Amzi! Prolog with a call like this:
?- replaceAtIndex(3, 0, [1,2,3,4,5,6], L).
L = [1, 2, 0, 4, 5, 6] ;
no
?-
But of course you also see success when the code is called in standalone/interpreted mode.
So I have to suspect the "index" argument being passed in is not an integer but rather a floating point number. Integer 1 will not unify with floating point 1.0, even if they are mathematically equal.
You can use the predicate is_integer/1 to test for this in Amzi! Prolog. The function integer(X) can be used to convert real 1.0 to an integer 1 by truncating the (nonexistent) fractional part.
Try _index_in_list set to 1. Wouldn't the first rule get called then?
Sure the reason why the second rule is getting called if your _index_in_list is 111 is because 111 is greater than 1 ? The first rule only deals with 1 - as the first parameter says.
When I'm replacing the _index_in_list with a constant 111 it
works.
What? You mean the first rule gets called? How can that be, the first param is 1.
replaceAtIndex(I, Value, List, Result) :-
RI is I-1,
findall(Before, (nth0(B, List, Before), B < RI), Before),
findall(After, (nth0(A, List, After), A > RI), After),
append([Before, [Value], After], Result).
?- replaceAtIndex(3,0,[1,2,3,4,5,6], L).
L = [1, 2, 0, 4, 5, 6].