Okay guys. We've had a huge argument etc. But now I'm asking if we can
just let sleeping dogs lie and start from scratch. As Larry Clapp said:
> I would suggest the following course of action: end /all/
> discourse in this particular thread, start/continue your next homework
> assignment, try your best, and then post specific questions about the
> problem(s) you've had with it, with sample code.
That's good advice, so I'm going to take it. I'm going to work on my
next assignment, and just watch the group for a while and learn.
I just hope that when I ask another question, you guys don't have this
preconception of me being dumb/stupid/slut/arrogant/everyotherinsult.
I'm really not any of these things, although I may have unintentionally
said things in the wrong way. I'm hoping for a fresh start here.
I'm just looking at the next assignment, and it we have to implement an
inference engine. It shouldn't be too hard I don't think. However, I'm
not sure you implement "Facts" in lisp? For example, we have to have
this fact in the knowledge base:
(likes phred roses)
So how do you go about this? I'm thinking that I may be reading into
this too much and making this look more difficult than it should be.
Should I just have a list of the facts, and then just parse the list
into atom's and match the atoms?
--
Mel
Please post reply to newsgroup. Reply address isn't valid.
arien <·············@getlost.invalid> wrote in
·······························@news.adl.ihug.com.au:
> Okay guys. We've had a huge argument etc. But now I'm asking if we can
> just let sleeping dogs lie and start from scratch. As Larry Clapp said:
why? How does that help me?
>
>> I would suggest the following course of action: end /all/
>> discourse in this particular thread, start/continue your next homework
>> assignment, try your best, and then post specific questions about the
>> problem(s) you've had with it, with sample code.
>
This advice applies to you. The people helping you were not screwwing
up,
> That's good advice, so I'm going to take it. I'm going to work on my
> next assignment, and just watch the group for a while and learn.
>
good
> I just hope that when I ask another question, you guys don't have this
> preconception of me being dumb/stupid/slut/arrogant/everyotherinsult.
> I'm really not any of these things, although I may have unintentionally
> said things in the wrong way. I'm hoping for a fresh start here.
I have no idea about your sexual habits, but the rest seems to fit. Now
if you want to change my opinion of you then change your behavior,
consistantly. You have been consistant up till now.
>
> I'm just looking at the next assignment, and it we have to implement an
> inference engine. It shouldn't be too hard I don't think. However, I'm
> not sure you implement "Facts" in lisp? For example, we have to have
> this fact in the knowledge base:
>
> (likes phred roses)
>
> So how do you go about this? I'm thinking that I may be reading into
> this too much and making this look more difficult than it should be.
> Should I just have a list of the facts, and then just parse the list
> into atom's and match the atoms?
>
alists/plists would be a place to start. Go to the hyperspec/your book
and read.
I am taking you at your word that you want to stop being a pain in the
ass.
good night
marc
arien wrote:...
> For example, we have to have
> this fact in the knowledge base:
>
> (likes phred roses)
> ...
> Should I just have a list of the facts, and then just parse the list
> into atom's and match the atoms?
That is what is most commonly done. There are an enormous number of
other approaches of course. A frequent complication is the use of a
persistent store (which is not needed in your assignment).
I'm a little confused by your use of "parse the list into atom's"
though. You're probably gonna have a fact matching function that
returns a list of facts that match a given pattern wherein each position
in the fact to match is either given by a literal or a special wildcard
value (perhaps using a more general internal form). In any case, the
list of facts is a list of lists as each fact is a list of three items.
Jim
arien wrote:
> I'm just looking at the next assignment, and it we have to implement an
> inference engine. It shouldn't be too hard I don't think.
I think you may be underestimating the complexity involved.
> However, I'm not sure you implement "Facts" in lisp? For example, we
> have to have this fact in the knowledge base:
>
> (likes phred roses)
For a start, there is description of this kind of thing either in `ANSI
Common Lisp' by Paul Graham or `Paradigms of Attificial Intelligence
Programming' by Peter Norvig aka PAIP.
> Should I just have a list of the facts, and then just parse the list
> into atom's and match the atoms
I *think* this would work in the simplest cases. Hoever, you may need a
more sophisticate approach. For example, will you have to deal with
stuff like: (not likes bert rubber ducky)?
:)w
arien <·············@getlost.invalid> wrote in message news:<··························@news.adl.ihug.com.au>...
> Okay guys. We've had a huge argument etc. But now I'm asking if we can
> just let sleeping dogs lie and start from scratch.
[snip]
> I'm hoping for a fresh start here.
groovy.
> I'm just looking at the next assignment, and it we have to implement an
> inference engine. It shouldn't be too hard I don't think. However, I'm
> not sure you implement "Facts" in lisp? For example, we have to have
> this fact in the knowledge base:
>
> (likes phred roses)
>
> So how do you go about this? I'm thinking that I may be reading into
> this too much and making this look more difficult than it should be.
> Should I just have a list of the facts, and then just parse the list
> into atom's and match the atoms?
You could refer Norvig and Russell's book Artificial Intelligence: A
Modern Approach (AIMA). They explain both forward and backward
chaining with pseudo-code. Also Norvig has implemented the code in
Lisp (and Python). His unification program's code has been taken from
his book PAIP.
Vijay L
arien <·············@getlost.invalid> wrote in message news:<··························@news.adl.ihug.com.au>...
> I'm just looking at the next assignment, and it we have to implement an
> inference engine. It shouldn't be too hard I don't think. However, I'm
> not sure you implement "Facts" in lisp? For example, we have to have
> this fact in the knowledge base:
>
> (likes phred roses)
>
> So how do you go about this?
Lisp is a general purpose programming language with a wealthy set of
data types. So you have a lot of choices when deciding how to
represent something.
> I'm thinking that I may be reading into
> this too much and making this look more difficult than it should be.
> Should I just have a list of the facts, and then just parse the list
> into atom's and match the atoms?
Sure, why not?
Why don't you do a web search for Lisp implementations of Prolog?
There are a few open source ones. There is one simple Prolog-like
system in the form of a single .lisp file that is 5 kilobytes long.
The internals of that can give you ideas how to represent facts and
perform unification.
arien wrote:
> Okay guys. We've had a huge argument etc. But now I'm asking if we can
> just let sleeping dogs lie and start from scratch. As Larry Clapp said:
>
>
>>I would suggest the following course of action: end /all/
>>discourse in this particular thread, start/continue your next homework
>>assignment, try your best, and then post specific questions about the
>>problem(s) you've had with it, with sample code.
> That's good advice, so I'm going to take it. I'm going to work on my
> next assignment, and just watch the group for a while and learn.
It is very good advice. As someone else pointed out, c.l.l has some
pretty smart contributors. You have found your way here- and here is a
place where the "hacker" culture (in the best sense of the word) lives.
It is one of the last places of which that is true. You assign a very
different meaning to the word "respect" than I do. Recognize that
respect that you earn here will actually be earned- and thus will be
valuable, in a way that respect that is just sort of handed out to the
first comer is not.
> I just hope that when I ask another question, you guys don't have this
> preconception of me being dumb/stupid/slut/arrogant/everyotherinsult.
> I'm really not any of these things, although I may have unintentionally
> said things in the wrong way. I'm hoping for a fresh start here.
And I'm sure you will be given one. The first step toward that would be
using a real email address (appropriately obfuscated if you have
inadequate spam protection). It is hard to take people seriously when
they refuse to identify themselves unambiguously. You might also find it
useful to take Mr. Nagger out of your killfile. His reactions are
sometimes disproportionate, but he knows a lot about lisp (and about
some other things too). If you really value learning you will swallow
your pride, and learn from him, even if you dislike him.
> I'm just looking at the next assignment, and it we have to implement an
> inference engine. It shouldn't be too hard I don't think. However, I'm
> not sure you implement "Facts" in lisp? For example, we have to have
> this fact in the knowledge base:
>
> (likes phred roses)
>
> So how do you go about this?
Go about what? The assignment must have had a bit more context than
that. You would be best to try to do it first, and ask questions about
specific problems you encountered while doing it.
<snip>
Tagore Smith
> That's good advice, so I'm going to take it. I'm going to work on my
> next assignment, and just watch the group for a while and learn.
Speaking of learning...
As you pointed out, it is wise to be suspicious of people who defend
something too vigorously. Lisp doesn't need much in the way of defense.
Not too many languages have lasted 40 years.
But there will always be people like the troll who posted the
venomous little screed above about C++. He had a point of course- more
people do program in c++ than in lisp. Why then do people use lisp, why
do people argue for it, when the majority disagrees? C.l.l occasionally
contains answers to that question (in between lambasting you). Your
initial post was titled "The difference between lisp and c++". And you
seem to not like the parentheses :). I'd like to give one small example
of how lisp differs from c++. It would be nice to see some others. Note
that this example is easy to write _because_ lisp uses prefix notation
and a lot of parentheses (for an even better example see the definition
of condlet in the same chapter).
I read Paul Graham's "On Lisp" a while back. It is one of the
classic Lisp books- maybe one of the best books about programming ever
written. Lately I've been rereading it, looking for things I missed the
first time through. The following is a macro that I came across in it
tonight (I believe this constitutes fair use):
(defmacro do-tuples/o (parms source &body body)
(if parms
(let ((src (gensym)))
`(prog ((,src ,source))
(mapc #'(lambda ,parms ,@body)
,@(map0-n #' lambda (n)
`(nthcdr ,n ,src)
(1- (length parms))))))))
(This uses a couple of functions that Graham has earlier declared).
I had to look at this twice to see what it did. I underatand what
mapcar (and mapc) does with lists of differing lengths, but it took me a
minute to see how that was used here. This code is pretty neat, in much
the same way that Perl code is often neat. But once you've understood
it, you can forget about the neatness and use it, as in Graham's example:
(do-tuples/o (x y) '(a b c d)
(princ (list x y)))
Entered at the toplevel this gives:
(A B)(B C)(C D)
NIL
This is just one macro from a book that's full of interesting code.
Do you see why this is useful? And why you cannot do it as
satisfactorily in Java, or c++?
Tagore Smith
Tagore Smith <······@tagoresmith.com> wrote in message news:<················@tagoresmith.com>...
> But there will always be people like the troll who posted the
> venomous little screed above about C++. He had a point of course- more
> people do program in c++ than in lisp. Why then do people use lisp, why
> do people argue for it, when the majority disagrees?
The majority is not *informed* enough to be capable of agreement or
disagreement. When just a few years ago I used C++ and not Lisp, it
wasn't because I disagreed about anything. I simply didn't know that
Lisp was this good. Now I know that, but C++ still pays the bills.
People are steered toward programming languages by forces that have
little to do with rational evaluation of all the available
alternatives. It's just a herd effect.
Tagore Smith <······@tagoresmith.com> writes:
> I read Paul Graham's "On Lisp" a while back.
...
> (defmacro do-tuples/o (parms source &body body)
> (if parms
> (let ((src (gensym)))
> `(prog ((,src ,source))
> (mapc #'(lambda ,parms ,@body)
> ,@(map0-n #' lambda (n)
> `(nthcdr ,n ,src)
> (1- (length parms))))))))
>
> (This uses a couple of functions that Graham has earlier declared).
>
...
>
> (do-tuples/o (x y) '(a b c d)
> (princ (list x y)))
>
> Entered at the toplevel this gives:
>
> (A B)(B C)(C D)
> NIL
>
> This is just one macro from a book that's full of interesting
> code. Do you see why this is useful? And why you cannot do it as
> satisfactorily in Java, or c++?
Maybe that's a bit much to ask. The full title of the book is
``On LISP: Advanced Techniques for Common LISP''
and I'd say it is quite well chosen. Lisp macros are amazing: Once
you've understood what they really are, they seem to be a simple and
obvious concept; however, by then you have already understood what
code-data-equivalence really means, and apparently coming to that
point is not so easy, as you'll realize every time you try to explain
it to somebody who hasn't arrived at that level yet. Remember that
``oleg'' troll a while ago? He'd probably post a thousand messages
now explaining to you how you can print (A B)(B C)(C D) in ML using
higher order functions -- (``See? No macros needed.''), totally
failing to get the point.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
>
> Maybe that's a bit much to ask. The full title of the book is
>
> ``On LISP: Advanced Techniques for Common LISP''
>
> and I'd say it is quite well chosen. Lisp macros are amazing: Once
> you've understood what they really are, they seem to be a simple and
> obvious concept; however, by then you have already understood what
> code-data-equivalence really means, and apparently coming to that
> point is not so easy, as you'll realize every time you try to explain
> it to somebody who hasn't arrived at that level yet.
Yeah, I don't necessarily expect arien to understand how the macro
does what it does. I'm certainly not an expert Lisp programmer, but I've
been using Lisp a lot longer than arien, and, as I said, it took me a
minute to see how it worked. What is understandable is the example, and
the fact that it does something a bit out of the ordinary- repeatedly
evaluates it's body with x and y rebound each time. It's very useful to
be able to extend the language like this, but it's hard to show it
without giving examples that are a bit above the head of a beginner.
Examples like that are an incentive for a beginner- learn Lisp and
you'll be able to do things like this with it. I took a couple of
courses taught in Scheme and Lisp when I was in school and macros were
never even mentioned. My guess is that very few of the students in those
classes ever programmed in Lisp again, and very few understood why they
would want to.
>Remember that
> ``oleg'' troll a while ago? He'd probably post a thousand messages
> now explaining to you how you can print (A B)(B C)(C D) in ML using
> higher order functions -- (``See? No macros needed.''), totally
> failing to get the point.
>
Or worse, a C programmer explaining that with a function pointer and
some unions... but let's not go there :).
Tagore Smith
In article <··························@news.adl.ihug.com.au>, arien
<·············@getlost.invalid> wrote:
>I'm just looking at the next assignment, and it we have to implement an
>inference engine. It shouldn't be too hard I don't think. However, I'm
>not sure you implement "Facts" in lisp? For example, we have to have
>this fact in the knowledge base:
>
>(likes phred roses)
>
>So how do you go about this? I'm thinking that I may be reading into
>this too much and making this look more difficult than it should be.
>Should I just have a list of the facts, and then just parse the list
>into atom's and match the atoms?
You haven't given us much information here. Is your teacher
so bad that this is all s/he has provided you?
Here are some questions you should be able to answer before
you start designing/coding your program:
As someone else mentioned, will logical combinations of facts
such as:
(and (likes phred roses) (not (likes phred roses)))
be in the database too?
What is the format of the inference rules? In particular,
are variables allowed, e.g.:
(IF (likes ?person roses)
THEN (likes ?person violets))
What is the regimen by which inference rules are applied to
facts to generate new facts? Backward or forward chaining?
Which of the possibly multiple matching inference rules at
each point in time is actually applied? Or are all applied?
Can the "then" side of inference rules delete facts from
the knowledge base, or can facts only be added?
A good teacher will also make available a mock trace of a
properly behaving system.
I hope this helps.
* arien <·············@getlost.invalid>
| Okay guys. We've had a huge argument etc. But now I'm asking if we can
| just let sleeping dogs lie and start from scratch.
You have that opportunity /all the time/. The moment you realize this
will be an important moment of enlightenment for you.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.