CSE630 Homework 1: Intelligence in general, Designing Intelligent Agents

Due Wednesday, October 3 at 4:00 A.M.
1 point late penalty for each minute late

Part 1: Intelligence and Rationality

(Note: Your responses to these questions must be submitted electronically. Please see the submission instructions below.
  1. (1 point) Contact info: 1) Subscribe to the CSE630 email list so you will get announcements emailed to the class. Also, make sure your name.num@osu.edu account is forwarded to the place you read email, in case we need to contact you individually.
  2. (10 points)Define in your own words: a) intelligence, b) artificial intelligence, c) agent.
  3. (10 points)
    a) (5 points) Interact with the winning system from the 2006 Loebner prize (and previous winners if you want) to get the flavor of this type of chat agent. Compare the behavior of the agent to *your* definition of intelligence. Does the agent satisfy your definition?
    b) (5-points) The Loebner contest is an attempt to implement the Turing test. State reasons why you think the Turing Test is or is not a good way to go about testing whether an entity is intelligent.
  4. (10 points) Suppose you are interacting with another person in an online chat forum. A mischievous friend has told that person that you are a very advanced chatbot, so now you must try to prove that you are in fact a person rather than a chatbot. All you have available for communicating is a text-based display. How would you go about it? Would your argument focus on reasoning capabilities or sensory abilities?
  5. (10 points) If a chess program can consistently beat its creator at chess, does that mean that it is more intelligent than the programmer? What does this imply about the often-cited criticism of AI: "Machines cannot be intelligent because they can only do what their programmers tell them to do".
  6. (9 points) Read the following stories from the Darwin Awards website (Warning: Some Darwin award stories contain graphic accounts of messy self-inflicted wounds. Stick to only the stories below if you are squeamish) : The agent described in each of these stories has done something irrational, but using what you have learned in this class, you can give a more precise reason for why the action was irrational. For each of these three stories, identify the point of failure that prevented each of these agents from completing his task in terms of the general agent design diagram of Figure 2.13. Was the fatal mistake a failure to correctly assess how the world evolves, what the world is like now (in other words, a failure to translate perceptions into knowledge), a failure to correctly assess which actions the agent could perform given the state of the world, or a failure to judge 'what will the world be like if I do action A'?

Part 2: Build a Simple Agent

Implement a simple agent in the programming language of your choice. The agent's task will be remote exploration, such as a very simple version of the Mars Rover. The agent can move from place to place and pick up soil samples for analysis. The purpose of this assignment is for you to become familiar with the difference between a simple reflex agent and a reflex agent with state.

You may write your agent from scratch or utilize the objects in the code repository provided with the textbook (with this caveat). I recommend that you draw on the pseudocode in the book to help design your agent. If you use the step names in the book such as Interpret-Input and Rule-Action (p. 47), it will be easy to extend your agent with new capabilities or port it to different applications in the future.

A simple reflex agent (25 points)

Build a reflex agent that probes the soil underneath its current location, reads the perception of the composition of that soil, and then collects a soil sample only if the soil composition matches a predefined specification of target compounds. The soil's composition is represented as an integer number, so the perception that the agent receives from its soil probe will be a numeric value. This agent can perform two possible actions: GRAB and NOOP. At each time interval, it should probe the soil, and either GRAB a sample if the probe value is a target compound, or NOOP if it is not (actually it will not be grabbing anything, it just writes the char 'G' or 'N' to stdout). We will pretend that this reflex agent is being moved around by remote control, so it does not need actions for moving. To keep things simple, the criteria for collecting a sample (GRAB) is if the soil compound id is evenly divisible by three. In other words, the agent should GRAB if it perceives 0, 3, 6, ..., and should NOOP if the percept is any other number.

Input: The percepts will be provided to the agent in a file, with one perception per line, and the perceptions will be represented as integers with a minimum value of 0 and maximum value of 20. The agent should accept its input file via stdin so that we can test the agent with different input files. The agent needs to run at the command ReflexRover like so (without the parens around the file name of course):

% ReflexRover < < filename >

A sample input file is provided here.

We have provided a function that reads the input file and provides percepts to the agent. The code is available in C++, Perl, Java, Lisp, C, Python, Resolve.

Output: The agent should output the percept it received at each time step and the action it chose to perform. Output should be to stdout in exactly this format:

Perceived: < X > Action: < action >

An example output sequence is:
Perceived: 1 Action: N
Perceived: 7 Action: N
Perceived: 0 Action: G
Perceived: 6 Action: G

Grading: To receive full credit on this assignment, your program must have a function with this declaration: char SimpleReflexAgent(int percept) that returns a character representing the action it took, and the output produced must be appropriate given the input file (we will use a different input file when we test your program).

A reflex agent with state (25 points)

Now we will extend the agent's behavior to be more autonomous by choosing its own movements, but the agent must choose its movements judiciously to avoid obstacles. The obstacles will be sensed using a vision sensor. We also want the robot to conserve energy, so it should make its best attempt to only visit each location once (if possible) and should GRAB a soil compound only if it doesn't already have a sample of that compound. The rover should pick up all samples that it hasn't yet collected (not just the ones divisible by three). Once again, writing the agent function to comply with the pseudocode in Figure 2.12 will help when it comes time to modify the agent's abilities or perceptions in future experimentation.

The picture above shows the sort of hardware platform you should imagine your software is controlling. A soil probe reads the soil composition at the rover's CURRENT location, and the camera looks out in front of the rover to plan its locomotion. Locations are descretized into a grid of x,y coordinates. The grid has only 2 rows (a top and bottom location) in each column, but it can have any number of columns. The grid has the standard cartesian orientation, with the southern-most row in row 1 (y=1), and the Westernmost column in column 1 (x=1). The robot's soil probe returns the same set of values as in the first part of this assignment. In addition, to plan the agent's movements, we will use the vision sensor that tells the robot whether the direction the camera is currently facing is CLEAR, meaning that the robot can move onto that position, or BOULDER, in which case the robot cannot move onto that grid position. Since the robot might damage itself running into the boulder, we want the robot to look at each location before attempting to move there. The robot must choose the direction to point the camera using the actions LOOKNORTH, LOOKSOUTH, LOOKWEST, LOOKEAST. The visual percept received by the agent depends on the direction the camera is pointing. For example, if the robot is at grid position (1,1) and looks EAST, the robot will see whether square (2,1) is clear or not. The agent should only move onto grid positions that are CLEAR. Movement is accomplished via a repertoire of new movement actions: GONORTH, GOSOUTH, GOEAST, GOWEST,

Beginning from (1,1) (a location that you may hard-code) the robot should traverse the grid and collect rock samples from each CLEAR position only when it perceives a compound that it has not previously collected. You should traverse the grid methodically, for example start at the western end of the grid and proceed by exploring each column, then moving east. You can also hard-code the direction that the camera is pointed at start-up.

Input
The input file for the agent will contain a description of its environment represented as a grid with either a Boulder or a numeric soil composition in each position. Since the agent now has two sensors, the percept for each grid position has two values: the number for the soil compound located at the robot's present position, and whether the direction the robot is looking is 'CLEAR' or 'BOULDER'. If the agent looks toward a direction that is outside of the defined grid (such as position (0,5) in the example), it will SEE a NULL.

Each row of the grid will be described on a separate line in this format:

row number, then pairs that describe the entries in that row: 'Clear'/'Boulder' and soil compound number

A sample input file is provided here.

Once again, we have provided a function that reads the input file and provides percepts to the agent. C++, Perl, Java, Lisp, C, Python and Resolve.

Here's a map corresponding to the grid in the sample input file:

--------------------------
| B  | 9  | B  | 1  | 6  |
--------------------------
| 0  | 15 | 4  | 4  | B  |
--------------------------
The corresponding positions are:
-------------------------------
| 1,2 | 2,2 | 3,2 | 4,2 | 5,2 |
-------------------------------
| 1,1 | 2,1 | 3,1 | 4,1 | 5,1 |
-------------------------------
The agent should run at the command-line like so (without parentheses around the file name) :

> StateRover < < filename >

Or alternately if written in a compiled language like java:

> java StateRover < < filename >

Output
The agent should output its current position at each time step, the perception it received and the action chosen, written to stdout in exactly this format:

Position: <row,col> Looking: (direction) Perceived: <Num,Status> Action: (action)

as well as a summary line showing how many compounds were collected and how many moves were made.
An example output sequence is shown below. The agent starts in square (1,1) looking South. Remember that the agent reads its sensors, then prints out the action it is about to do, so the second line of output says 'LOOKEAST', the robot turns its camera east, and the sensor readings shown on the third line reflect the fact that the rover is sill reading the soil sample from position (1,1) and is now getting the vision perception from square (2,1). This output does not necessarily contain the optimal sequence of actions for the agent:

Position: <1,1> Perceived: <0,NULL> Action: LOOKNORTH
Position: <1,1> Perceived: <0,BOULDER> Action: LOOKEAST
Position: <1,1> Perceived: <0,CLEAR> Action: GOEAST
Position: <2,1> Perceived: <15,CLEAR> Action: GRAB
Position: <2,1> Perceived: <15,CLEAR> Action: LOOKWEST
Position: <2,1> Perceived: <15,CLEAR> Action: LOOKNORTH
...

Total Compounds Collected: 1 Total Moves: 1
Grading: To receive full credit on this assignment, your program should include an agent function called ReflexAgentWithState(percept) that returns an action, and the output produced much be appropriate given the input file we will specify for the agent when we test your program.

Submission instructions:

We will test your program on the CSE dept unix computers (stdsun), so make sure that the program you turn in is built to run on Solaris. Don't depend on cross-platform language implementations. If your program doesn't execute successfully, we will not attempt to recompile it or otherwise correct the error. Your program will be graded solely on whether its actions are appropriate to the inputs we supply in our testing, not on your programming style or design sophistication.

What to turn in

  1. Turn in your answers to questions 2 through 6 in either a text file (.txt extension) or a pdf so that they can be viewed on stdsun.
  2. For the code, you should turn in either
    • An executable version of your program along with the source code.
    • If your program is written in an interpreted language, such as perl, lisp or python, you can turn in just the source.
    Make sure to use a standard file extension in naming your files.
  3. Create a README file that instructs the grader how to execute your programs.
  4. Put the files that you want to turn in, and ONLY those files, in a directory called hw1 on your stdsun account.
Make sure that your name appears on all files that you turn in.

How to turn it in

Submit your files electronically using the submit command on stdsun. Remember that submit over-writes your entire directory, so you cannot submit individual files. Submit early with the files you have completed well ahead of the deadline as a safeguard. From the directory above the hw1 directory you created in step 4 above, the syntax of the submit command is:

> submit c630aa lab1 hw1

You can learn about using the submit command by typing man submit at a unix command prompt. If you cannot get the submit command to work, you can email your files to the grader, but please don't use this option unless you're having trouble with submit. Important Note Every so often, a student claims to have submitted their program, yet it does not show up in the grader's submit directory, so I advise you to save the confirmation you receive from submit that shows the time stamp of your submission (and also says where you sent the files).

Code Repository Disclaimer

The code repository provided by the textbook authors is most likely very reliable code, however, be warned that I haven't tested it and don't guarantee that it will work as described. If you decide to use code from the repository, don't expect your instructor or the grader to debug it for you.

Also, any code you use from the repository should be clearly credited. Do not make it appear to be your own work.