« Open source leads to outsourcing? Hardly | Main | REST WARS »

Faults of Omission (aka the Frame Problem)

I don't know if this is a true story, but it's truly a story I've heard. A new jet fighter was being tested. The test pilot strapped in, turned the key in the ignition (or the equivalent), and flipped the switch to raise the landing gear. The plane wasn't moving, but the avionics software dutifully raised the landing gear. The plane fell down and broke. Brian Marick

That is a Fault of Omission.

Once upon a time there was a robot, name R1 by its creators. Its only task was to fend for itself. One day its designers arranged for it to learn that its spare battery, its precious energy supply, was locked in a room with a time bomb set to go off soon. R1 located the room, and the key to the door, and formulated a plan to rescue its battery. There was a wagon in the room, and the battery was on the wagon, and R1 hypothesized that a certain action which it called PULLOUT(WAGON,ROOM) would result in the battery being removed from the room. Straighaway it acted, and did succeed in getting the battery out of the room before the bomb went off. Unfortunately, however, the bomb was also on the wagon. R1 knew that the bomb was on the wagon in the room, but didn't realize that pulling the wagon would bring the bomb out along with the battery. Poor R1 had missed that obvious implication of its planned act. Daniel Dennett

That is the Frame Problem.

I remember one of the first AI programs I wrote. It was a simple block worlds solver written in Prolog. Blocks world, if you don't know, is a classic AI problem domain. It usually consists of a number of objects like tables, blocks ground and so on. You instruct the program to configure the blocks in a certain way and it it uses it rules and domain knowledge to achieve the goal. The first cut of the program seemed to be going very well, the solver was doing a good job rearranging things - until it tried to put the ground on the table. Bill de hra

That is Somewhere Between The Two.

By the way, if you're into testing, Brian Marick is a must read.


January 28, 2004 11:45 PM

Comments

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1148