Advice etc. About Assignment 0

Friday 19 September: Be careful how you change the grid

When you are determining the number of live neigbours for a given cell, this must be the number from the previous generation, not the partially-computed next generation. For example, consider the following pattern (say cells a and b are empty):

      -------
      --XaX--
      ---Xb--
      -------

The cell marked a has three X's around it, so it will be born in the next generation. But that to-be-born cell does not count as a live neighbour of the cell marked b.

It's as if the all births and deaths for the next generation happen simultaneously. But, of course, you have to compute the changes one at a time. While doing this, you can't simply make immediate updates to theGrid, or your code will not handle examples like the one above properly.

Friday 19 September: What you need to know

Many students are feeling overwhelmed by the starter code. One lesson that this assignment is intended to teach you is that when you are using a class, you need to know only its "interface". This includes

the declarations of any public data members, and
the declarations of any public methods. That means only the "header" or "signature" of the method, not its body. You will also need to look at the comments at the very top of the method. If they are written properly, they will tell you everything you need to know about what the method does under all circumstances. You do not need to know how it does it.

Suggestion: Take each class from the starter code and use a highlighter pen to mark its interface. Then don't worry about anything else in the code!

When writing your nextGeneration method, you should focus on the Grid class. You will need to be aware of the variable defined at the top:

      Cell [][] theGrid;

since it stores the actual grid which it's your job to update. When you are working out your nextGeneration algorithm and code, think about which of those methods that you highlighted might perform a service that you can use. Almost all of them are not relevant to you, but at least one is: the evolve method defined in both LiveCell and EmptyCell. It does a lot of the nextGeneration logic ("if I have 3 neighbours then ..." and so on). Both LiveCell and EmptyCell have this method, so if you have a reference to a Cell you can tell it to evolve itself, even though you don't know which kind of Cell it is. Java knows, and will therefore call the right evolve method.

Now if you're going to tell a Cell to evolve itself, it needs to be told the number of LiveCells that it has as neighbours. (See the parameter list for evolve.) So you'll have to count up the live neighours first. In order to count up the live neighbours, you need some way to find out whether or not a given Cell is a LiveCell. Say you want to know if Cell (3,8) is live. The best way to do this is to say:

     if (theGrid[3][8] instanceof LiveCell) ...

"instanceof" is a keyword in Java. Standish introduces it in appendix A.

Another way to find out if a cell is live is to look at the cell's "ident" variable. This is definitely not as good a way to do it. Think about why not.

Friday 19 September: Stable states

When discussing the game of life in general, the handout talks about how a steady state can be reached. However, our program will not detect steady states; it will always run for the desired number of generations. You should not try to change this -- it involves code outside of where you are to be working.

Friday 19 September: Neighbours again

In my posting below, I talk about cell (0,0) having 8 neighbours. I don't mean live neighbours, just neighbouring cells.

Thursday 18 September: Clarifying what neighbours are

Question: I have a question about he life game. On the handout it says that we should have a continuous grid (like a donut). In the example below, how many neighbors does the organism on (0,0) have?

    X-----
    -----X
    ------
    XXX--X

Answer: It has 8 neighbours, one of which is (5,5) -- the cell at the lower right corner.

Thursday 18 September: Importing the starter code

Some students are having trouble importing the starter code into visualAge. Read page 33 of the Don't Panic Guide for details, but here's a quick summary of steps for importing the Life files:

From the File menu select Import
Type "Life" in the project field
Click the "Show all files" checkbox
Browse the big text field
Select the directory where you have saved the files to be imported
Click Finish

To Export the Life files:

Select Life in the project list
From the File menu select Export
Choose the directory
Select the "Use one directory" option
Click Browse

If you get stuck with things like this -- things about visualAge -- the best thing to do is go to a tutor office hour where you can show them your problem in person. (But please be patient; visualAge has only existed for a short time and we're all trying to get used to it.)

Thursday 18 September: Handing in your assignment

Question: I have several questions reagarding submitting assignment 0: 1) Which part of the code should we submit ? The whole starter code including the method we are supposed to write (nextGeneration()) or just the grid class that contains the method nextGeneration() and then rename it as Life.java ?
Answer: I had to be vague about this in the handout because details of the "hand in" feature weren't available. I will give you more detailed instructions later in a web posting.
Question: 2) How to export the code into a single text file using VA Java ?
Answer: It turns out that it can't be done. I'll explain what to do instead in my posting.
Question: 3) I don't see any "File Utilities" icon on the PCs in the lab. Are those command not yet ready ?
Answer: It's not there yet, but it will be.