Re: lists
From: flapper (none_at_a.b.c.dINVALID)
Date: 04/29/04
- Next message: ajam4_at_op.pl: "Re: A simple (?) graph algorithm"
- Previous message: Neil York Oliver: "need help for this procedure"
- In reply to: Neil York Oliver: "Re: lists"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 29 Apr 2004 08:01:59 GMT
Neil York Oliver wrote:
> "flapper" <none@a.b.c.dINVALID> wrote in message
> news:tqXjc.8629$Fo4.111841@typhoon.sonic.net...
>
>> It doesn't seem to me that what you have said about the problem is
>>enough to solve it. In other words,
>>
>> select_action(LOC,[ITEM|INTENTIONS],ACTION) if what?
>>
>>
>
> Hi,
>
> Here is the detailed description in plain text..
Sorry, I didn't make myself clear.
I meant to say, /you/ have to work out the "what" part.
At the very least, you have to identify and define all the domains
and predicates involved in the problem and repeatedly rewrite each of
the requirements contained in the problem description until it becomes
clear to you how they can be translated into Prolog rules.
This process is not unlike the process of developing a Prolog
program: you write down your current understanding of what the problem
description says and you test that understanding by seeing if it can be
translated into Prolog; it it can, and your understanding of what the
problem description says is correct -- i.e., if your Prolog program
gives the right answers -- you are done; otherwise, you have to revise
your current understanding of what the problem description says and try
again; if this process goes into a loop, there may be aspects of the
problem description that need to be renegotiated.
For example, the problem description you were given says
"The agent's prioritization strategy is very simple: each new goal
***is inserted into*** the list of intentions in order of the closeness
of the item to the agent's current position (closer items coming earlier
in the list).
"However, once a goal is incorporated into the list of intentions, it
is never re-prioritized with respect to existing goals as the agent
moves about (hence after some time the list may not accurately reflect
the closeness of food to the agent)."
That doesn't seem like a good idea to me. I would probably consider
the list of goals without regard to order and define a predicate
next_goal(CurrLoc,CurrGoals,NextGoal,RemainingGoals)
that picks out the goal that really is closest to the agent's current
position, which I could then redefine as
next_goal(_,[NextGoal|RemGoals],NextGoal,RemainingGoals).
(Hobson's Choice) if I had to.
Also, it is not clear to me if or how the board is initialized.
If the board is initially empty, all the agent would have to do is
wait until an item spontaneously appeared in any of its 8 surrounding
squares and eat it immediately. Why go hunting when you can reach up and
pick a fresh peach right off the tree?
And, if an item appears out of nowhere, what determines its value?
Etc.
A very interesting problem.
Good luck.
-- sequitur AT sonic DOT net Maximize end-user autonomy.
- Next message: ajam4_at_op.pl: "Re: A simple (?) graph algorithm"
- Previous message: Neil York Oliver: "need help for this procedure"
- In reply to: Neil York Oliver: "Re: lists"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
