PhD Progress: A Relational Example

An example action in the Shepherding domain:
move(Dog1, LocationFrom(location(Flock3), -90°, DetectionRadius(Flock3) + DetectionRadius(Dog1))

This is saying, move Dog1 to South of Flock3, at a distance on the very border of the flock’s detection radius.

Breaking this down into general predicates:

  • move(#$Dog, #$Point)
  • #$Dog = {Dog1, Dog2, etc} depending on dog number
  • #$Point = {pointFunction(?), (0,0), (width,0), (width,height), (0,height), (width/2,height/2)}
  • pointFunction(?) => (x,y) = {location(#$Thing), locationFrom(#$Point, #$Angle, #$Length)
  • #$Thing = {#$Dog, #$Sheep, Goal}
  • #$Angle = {angleFunction(?), 0°, 30°, 60°, 90°, 120°, 150°, 180°, -30°, -60°, etc}
  • angleFunction(?) => d° = {calcAngle(#$Point, #$Point, #$Point)}
  • #$Length = {lengthFunction(?) => # >= 0 = {distance(#$Point, #$Point), detectionRadius(#$Thing), detectionRadius(#$Thing) + detectionRadius(#$Dog)}

There is a problem with this representation though. The representation strives to maintain a finite number of possible predicates and functions, but a loop is introduced with the locationFrom function. This function recurses back upon itself (both under #$Point and #$Angle, which takes a little longer, but can possibly extend).

To stop this infinite loop, a restriction should be placed that a function cannot be inside itself (locationFrom(locationFrom(…), …) = NO!).

By this logic, the environment should have a finite number of possible things within it. The problem then lies in the fact that it could have a possibly infinite number of objects within it (Infinity sheep). This also, could be abstracted by using functions and disallow constants. So instead of Dog1, we could use nearestDog(#$Point) or randomDog().

This raises an interesting question. Can an environment be represented purely in predicates and functions? No constants? One would think so, but is it effective?

A further issue is how the rules will be generated. Sure, this sort of rule could be generated randomly, but the more general form of the rule move(X, locationFrom(location(Y), -90°, detectionRadius(Y) + detectionRadius(X)) will probably not, unless some form of post-processing is run across the constants. Of course, without using constants, this becomes more likely, but still improbable. Perhaps introducing variables will dynamically increase the sets from which objects are retrieved from (so #$Dog may become {Dog1, Dog2, X} after introducing variable X in a #$Dog slot.

Another issue is that of subclassing. Because #$Dog, #$Sheep and Goal are all of #$Thing, when trying to extract a random #$Thing, we will need to look at all possible subclasses of #$Thing.

This may not be necessary with functions, as they will behave like constants. So, we can choose a random function/constant from the sets. Then, if it is a function, look at the values within it.

I think I should explicitly disallow looping functions. If I am to implement this in a pre-existing logical inference engine (I think Cyc may be too slow for this, although if I restrict it to inference within a particular microtheory, it might be alright), implementing a stopping condition would be tricky. Unfinished…