AP Computer Science

In week 6 we mostly talked about “Choreographers.”

Question: is there any reason why Robots can’t create other Robots?
Answer: no.

EXAMPLE:

public class SomeBot extends Robot{

    //...typical constructor

    public void makeNBots(int n){

        if(n>0){
	  OtherBot foo = new OtherBot(1,n,Directions.North,0);
          foo.go();
	}
    }

}

The code above is for a robot that can create some number of robots on street 1 and tell each one to go().

Question: What happens to all those robots once they’re done with their work?
Answer: nothing really. Our code will lose the reference to each robot object, but that doesn’t mean the robot ceases to exist. It will finish its work and stay in the world even though our code will not be able access it.

…Which brings up an important point. You need to think of Robot variables simply as named references to robot objects.

Robot foo = new Robot( 5, 5, North, 0);

                     _______
foo --------------->| Robot |
                    |-------|
                    | st=5  |
                    | ave=5 |
                    | dir=N |
                    | beep=0|
                    |_______|

If the code then says:
foo = new Robot(1,1,South,7); The reference named “foo” will simply be re-assigned to point to a different Robot.

                   _______
foo_              | Robot |
    \             |-------|
     \            | st=5  |
      \           | ave=5 |
       \          | dir=N |
        \         | beep=0|
         \        |_______|
          \         _______
           -------->| Robot |
                    |-------|
                    | st=1  |
                    | ave=1 |
                    | dir=S |
                    | beep=7|
                    |_______|

Thus, the first robot still exists, it’s just that “foo” doesn’t reference it anymore.

This has some rather large implications for how we think about robot programs. It means there is NO COST associated with creating a destroying or forgetting about robots. We can design robots to complete very small tasks that are part of a larger problem. Then we can create them to do one small task, and then forget about them.

When one robot creates other robots to do portions of its work, we call that a “Choreographing” robot, because it is choreographing the actions of many other robots with the big picture in mind.

The example we did in class of this was the Multiplier robot (project: Multiplier.zip)

Multiplier created two robots, one each on top of a pile of beepers. Each robot counted the pile of beepers it was standing on. Multiplier then asked each robot for its count, and created a third robot to put that many beepers down. The Multiplier was the choreographer in this case. Thus, the crucial section of the Multiplier code looked something like this:

//...Normal class declaration, header, constructor, etc.

public void multiply(){
  CounterBot one = new CounterBot(7,5,Directions.North,0);
  CounterBot two = new CounterBot(6,5,Directions.North,0); 

  int result = one.countBeepers() + two.countBeepers();
  PlacerBot ans = new PlacerBot(5,5,Directions.North, result);
  ans.putAllBeepers();
}

Then came the final question: does a Choreographer have to be a robot?
Answer: no.

As you can see from the code above, the Multiplier actually isn’t doing anything robot-ish. It’s just sitting there, creating robots, asking them for values and doing calculations. So, in fact, the Multiplier is a non-Robot class. It does not need to extend Robot and it can have an empty Constructor. It can be declared like so:

public class Multiplier{
  public Multiplier(){}
  ...
}

Henceforth, we can use non-robot classes to setup and coordinate the actions of many robots to complete more complicated tasks. This was the idea behind the DecoderBot project.