Well, in the language I normally use to discuss AI planning, this would mean that
1)keeping charged is a supergoal 2) The system knows (via hard-coding or learning) that finding the recharging socket ==> keeping charged (i.e. that the former may be considered a subgoal of the latter) 3) The system then may construct various plans for "find the recharging socket", and these plans may involve creating various subgoals of this subgoal -- Ben On 11/22/06, Bob Mottram <[EMAIL PROTECTED]> wrote:
Things like finding recharging sockets are really more complex goals built on top of more primitive systems. For example, if a robot heading for a recharging socket loses a wheel its goals should change from feeding to calling for help. If it cannot recognise a deviation from the "normal" state then it will fail to handle the situation intelligently. Of course these things can be "hard coded", but hard coding isn't usually a good strategy, other than as initial scaffolding. Systems which are not adaptable are usually narrow and brittle. On 22/11/06, Charles D Hixson <[EMAIL PROTECTED]> wrote: > I don't know that I'd consider that an example of an uncomplicated > goal. That seems to me much more complicated than simple responses to > sensory inputs. Valuable, yes, and even vital for any significant > intelligence, but definitely not at the minimal level of complexity. > > An example of a minimal goal might be "to cause an extended period of > inter-entity communication", or "to find a recharging socket". Note > that the second one would probably need to have a hard-coded solution > available before the entity was able to start any independent > explorations. This doesn't mean that as new answers were constructed > the original might not decrease in significance and eventually be > garbage collected. It means that it would need to be there as a > pre-written answer on the tabula rasa. (I.e., the tablet can't really > be blank. You need to start somewhere, even if you leave and never > return.) For the first example, I was thinking of "peek-a-boo". > > Bob Mottram wrote: > > > > Goals don't necessarily need to be complex or even explicitly > > defined. One "goal" might just be to minimise the difference between > > experiences (whether real or simulated) and expectations. In this way > > the system learns what a normal state of being is, and detect deviations. > > > > > > > > On 21/11/06, *Charles D Hixson* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Bob Mottram wrote: > > > > > > > > > On 17/11/06, *Charles D Hixson* < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto: [EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>>> wrote: > > > > > > A system understands a situation that it encounters if it > > predictably > > > acts in such a way as to maximize the probability of > > achieving it's > > > goals in that situation. > > > > > > > > > > > > > > > I'd say a system "understands" a situation when its internal > > modeling > > > of that situation closely approximates its main salient > > features, such > > > that the difference between expectation and reality is minimised. > > > What counts as salient depends upon goals. So for example I > > could say > > > that I "understand" how to drive, even if I don't have any detailed > > > knowledge of the workings of a car. > > > > > > When young animals play they're generating and tuning their models, > > > trying to bring them in line with observations and goals. > > That sounds reasonable, but how are you determining the match of the > > internal modeling to the "main salient features". I propose that > > you do > > this based on it's actions, and thus my definition. I'll admit, > > however, that this still leaves the problem of how to observe what > > it's > > goals are, but I hypothesize that it will be much simpler to > > examine the > > goals in the code than to examine the internal model. > > > > ----- > > This list is sponsored by AGIRI: http://www.agiri.org/email > > To unsubscribe or change your options, please go to: > > http://v2.listbox.com/member/?list_id=303 > > > > > > ------------------------------------------------------------------------ > > This list is sponsored by AGIRI: http://www.agiri.org/email To > > unsubscribe or change your options, please go to: > > http://v2.listbox.com/member/?list_id=303 > > ----- > This list is sponsored by AGIRI: http://www.agiri.org/email > To unsubscribe or change your options, please go to: > http://v2.listbox.com/member/?list_id=303 > ________________________________ This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303
----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303
