I'm using forward chaining algorithm proposed by Bratko. How can I enter arithmetic rules in prolog DB. For example I want to enter age is 35. In other words I want to enter the fact(age,35).
Thanks
Much depends on which Prolog you're using.
I think it's safe to presume the availability of assert/1, and the 'inverse' retract/1. The code you linked already uses assert/1.
Some Prolog requires the declaration of predicates to be manipulated via assert/retract:
:- dynamic fact/2.
...
assert(fact(age, 35)),
...
retract(fact(Kind, Value)),
write(Kind:Value),
...
Related
just started programming with prolog and I'm having a few issues. I wanna store the result on an operation , for example:
transformer(kilo,1000).
transformer(hecto,100).
transformer(deca,10).
transformer(unite,1).
transformer(deci,0.1).
transformer(centi,0.01).
transformer(milli,0.001).
transformerT(sec,1).
transformerT(min,60).
transformerT(h,3600).
plus(V1,U,V2,U,UniteType,R,U) :-
dif(UniteType,temps),R is V1+V2.
plus(V1,U1,V2,U2,UniteType,R,unite) :-
dif(UniteType,temps),
dif(U1,U2),
trans(U1,Res1),
trans(U2,Res2),
R is V1*Res1+V2*Res2.
I want to store the result of this operation to call it later (like the ANS or M Buttons in a calculator) in another operation. Is it Possible?
If you want the information to survive a program termination (i.e. a return to the Prolog REPL, aka. toplevel) you can use predicates asserta/2 and assertz/2.
See this section for SWI Prolog, should be similar for SICStus: Database
Alternatively you may want to keep the program "alive" and store information in a term that is passed between predicates. Association lists library(assoc) or, for SWI Prolog, built-in dicts, or simpler data structure like lists can be used for that.
So how are OR conditions emulated/invoked in Datalog-land ?
This is probably the most basic question ask-able about DataLog but well hello this is my first attempt at using it ;)
Got it now: it's a strange syntax: disjunction is created by having multiple rules with the same name
myrecursive(X,Y) :- basecase1(Y,X).
myrecursive(X,Y) :- myrecursive(X,Z),myrecursive(Z,Y).
This means that a descendant may satisfy either of those two rules.
Prolog's grammar uses a <head> :- <body> format for rules as such:
tree(G) :- acyclic(G) , connected(G).
, denoting status of G as a tree depends on status as acyclic and connected.
This grammar can be extended in an implicit fashion to facts. Following the same example:
connected(graphA) suggests connected(graphA):-true.
In this sense, one might loosely define Prolog facts as Prolog rules that are always true.
My question: Is in any context a bodiless rule (one that is presumed to be true under all conditions) ever appropriate? Syntactically such a rule would look as follows.
graph(X). (suggesting graph(X):-true.)
Before answering, to rephrase your question:
In Prolog, would you ever write a rule with nothing but anonymous variables in the head, and no body?
The terminology is kind of important here. Facts are simply rules that have only a head and no body (which is why your question is a bit confusing). Anonymous variables are variables that you explicitly tell the compiler to ignore in the context of a predicate clause (a predicate clause is the syntactical scope of a variable). If you did try to give this predicate clause to the Prolog compiler:
foo(Bar).
you will get a "singleton variable" warning. Instead, you can write
foo(_).
and this tells the compiler that this argument is ignored on purpose, and no variable binding should be attempted with it.
Operationally, what happens when Prolog tries to prove a rule?
First, unification of all arguments in the head of the rule, which might lead to new variable bindings;
Then, it tries to prove the body of the rule using all existing variable bindings.
As you can see, the second step makes this a recursively defined algorithm: proving the body of a rule means proving each rule in it.
To come to your question: what is the operational meaning of this:
foo(_).
There is a predicate foo/1, and it is true for any argument, because there are no variable bindings to be done in the head, and always, because no subgoals need to be proven.
I have seen at least one use of such a rule: look at the very bottom of this section of the SWI-Prolog manual. The small code example goes like this:
term_expansion(my_class(_), Clauses) :-
findall(my_class(C),
string_code(_, "~!##$", C),
Clauses).
my_class(_).
You should read the linked documentation to see the motivation for doing this. The purpose of the code itself is to add at compile time a table of facts to the Prolog database. This is done by term expansion, a mechanism for code transformations, usually used through term_expansion/2. You need the definition of my_class/1 so that term_expansion/2 can pick it up, transform it, and replace it with the expanded code. I strongly suggest you take the snipped above, put it in a file, consult it and use listing/1 to see what is the effect. I get:
?- listing(my_class).
my_class(126).
my_class(33).
my_class(64).
my_class(35).
my_class(36).
true.
NB: In this example, you could replace the two occurrences of my_class(_) with anything. You could have just as well written:
term_expansion(foobar, Clauses) :-
findall(my_class(C),
string_code(_, "~!##$", C),
Clauses).
foobar.
The end result is identical, because the operational meaning is identical. However, using my_class(_) is self-documenting, and makes the intention of the code more obvious, at least to an experienced Prolog developer as the author of SWI-Prolog ;).
A fact is just a bodiless rule, as you call it. And yes, there are plenty of use cases for bodiless facts:
representing static data
base cases for recursion
instead of some curly brace language pseudo code
boolean is_three(integer x) {
if (x == 3) { return true; }
else { return false; }
}
we can simply write
is_three(3).
This is often how the base case of a recursive definition is expressed.
To highlight what I was initially looking for, I'll include the following short answer for those who might find themselves asking my initial question in the future.
An example of a bodiless rule is, as #Anniepoo suggested, a base case for a recursive definition. Look to the example of a predicate, member(X,L) for illustration:
member(X,[X|T]). /* recursive base case*/
member(X,[H|T]):- member(X,T).
Here, the first entry of the member rule represents a terminating base case-- the item of interest X matching to the head of the remaining list.
I suggest visiting #Boris's answer (accepted) for a more complete treatment.
I am very new to Prolog and trying to learn.
For my program, I would like to have the user provide pairs of strings which are "types of".
For example, user provides at command line the strings "john" and "man". These atoms would be made to be equal, i.e. john(man).
At next prompt, then user provides "man" and "tall", again program asserts these are valid, man(tall).
Then the user could query the program and ask "Is john tall?". Or in Prolog: john(tall) becomes true by transitive property.
I have been able to parse the strings from the user's input and assign them to variables Subject and Object.
I tried a clause (where Subject and Object are different strings):
attribute(Subject, Object) :-
assert(term_to_atom(_ , Subject),
term_to_atom(_ , Object)).
I want to assert the facts that Subject and Object are valid pair. If the user asserts it, then they belong to together. How do I force this equality of the pairs?
What's the best way to go about this?
Questions of this sort have been asked a lot recently (I guess your professors all share notes or something) so a browse through recent history might have been productive for you. This one comes to mind, for instance.
Your code is pretty wide of the mark. This is what you're trying to do:
attribute(Subject, Object) :-
Fact =.. [Object, Subject],
assertz(Fact).
Using it works like this:
?- attribute(man, tall).
true.
?- tall(X).
X = man.
So, here's what you should notice about this code:
We're using =../2, the "univ" operator, to build structures from lists. This is the only way to create a fact from some atoms.
I've swapped subject and object, because doing it the other way is almost certainly not what you want.
The predicate you want is assertz/1 or asserta/1, not assert/2. The a and z on the end just tells Prolog whether you want the fact at the beginning or end of the database.
Based on looking at your code, I think you have a lot of baggage you need to shed to become productive with Prolog.
Prolog predicates do not return values. So assert(term_to_atom(... wasn't even on the right track, because you seemed to think that term_to_atom would "return" a value and it would get substituted into the assert call like in a functional or imperative language. Prolog just plain works completely differently from that.
I'm not sure why you have an empty variable in your term_to_atom predicates. I think you did that to satisfy the predicate's arity, but this predicate is pretty useless unless you have one ground term and one variable.
There is an assert/2, but it doesn't do what you want. It should be clear why assert normally only takes one argument.
Prolog facts should look like property(subject...). It is not easy to construct facts and then query them, which is what you'd have to do using man(tall). What you want to say is that there is a property, being tall, and man satisfies it.
I would strongly recommend you back up and go through some basic Prolog tutorials at this point. If you try to press forward you're only going to get more lost.
Edit: In response to your comment, I'm not sure how general you want to go. In the basic case where you're dealing with a 4-item list with [is,a] in the middle, this is sufficient:
build_fact([Subject,is,a,Object], is_a(Subject, Object)).
If you want to isolate the first and last and create the fact, you have to use univ again:
build_fact([Subject|Rest], Fact) :-
append(PredicateAtoms, [Object], Rest),
atomic_list_concat(PredicateAtoms, '_', Predicate),
Fact =.. [Predicate, Subject, Object].
Not sure if you want to live with the articles ("a", "the") that will wind up on the end though:
?- build_fact([john,could,be,a,man], Fact).
Fact = could_be_a(john, man)
Don't do variable fact heads. Prolog works best when the set of term names is fixed. Instead, make a generic place for storing properties using predefined, static term name, e.g.:
is_a(john, man).
property(man, tall).
property(john, thin).
(think SQL tables in a normal form). Then you can use simple assertz/1 to update the database:
add_property(X, Y) :- assertz(property(X, Y)).
I have the following prolog code:
equiAngularTriangle(T) :-
equiLateralTriangle(T).
equiLateralTriangle(T) :-
equiAngularTriangle(T).
Is there a way to keep the interpreter from asking the same question twice? For instance, if I ask equiAngularTriangle(t), then it's going to ask equiLateralTriangle(t), then ask equiLateralTriangle(t), but it should know not to pursue that last one again, because the same question is on the "query stack".
Is there an option or some special syntax that lets Prolog behave the way I want it to?
If the prolog implementation supports tabling or you are using XSB then you could use it and get the desired behaviour.
You could also add a state argument:
%State = [Checked_for_equiAngular, Checked_for_equiLateral]
equiAngularTriangle(T, [_,false]) :-
equiLateralTriangle(T, [true,true]).
equiLateralTriangle(T, [false,_]) :-
equiAngularTriangle(T, [true,true]).
of course you will need to modify the rest of the clauses.
The last (and best imo) option is to rewrite your predicates. I guess that your code will be similar to this example:
ang(T):-
foo(T).
ang(T):-
lat(T).
lat(T):-
bar(T).
lat(T):-
ang(T).
so you could simply write:
ang(T):-
foo(T).
ang(T):-
bar(T).
lat(T):-
ang(T).
normally you will use some wrapper predicates if instead of foo(T) you had foo1(T),foo2(T) etc
Try XSB Prolog. It implements tabling which will short-circuit evaluation like in your case. You need to tell it which predicates should be tabled, though.