Question text in black, answers in blue.
highLargestCont and lowLargestCont are
supposed to do.
highLargestCont. Another grid has a largest continent that is
smaller than (or the same size as) the largest continent on any of the other
grids -- this should be the output of lowLargestCont.
MapGrid instance that is calling the methods. Would it
make more sense for these methods to be static?
highLargestContinent struck me as inefficient, because every
time I took a MapGrid out of my list I went through the whole calculation to
find the capitals of all the continents, and then the size of the largest
continent. Would it make more sense to do this calculation just once, and
stort the result in an instance variable of the MapGrid object?
Yes, I agree. A MapGrid object isn't going to change once it is created.
So when it is created (in its contructor) it's sensible to do all the
calculations necessary to have the output of continentTable
ready to go. The information that the four Project #4 methods needs is in
that continent table, so those methods can get it from instance fields of
the MapGrid objects rather than have to compute it over. In DJW's terms,
it makes sense for all the output methods of both projects to be observers.
capitalMap
method works almost correctly with the test driver, except that in the last
test it puts two of the capitals in a different place. These are for continents
where two squares are tied for minimum centrality.
I had two different people in office hours this afternoon with exactly this problem. What both were doing to find capitals was this -- when they first encountered a continent in their sweep they stopped the sweep, searched over the continent for a better capital, and marked the capital as the first square they found with minumum centrality. What I would do is to continue the sweep, remembering the location and centrality of the first square found on the continent, until or unless we find a square on the same continent with smaller centrality. This will visit the tied squares in the intended order and thus return the first square with minimum centrality as the capital.
continentTable, I got two continents in the wrong order because
when I swept the grid looking for capitals, I found the capital of K before
the capital of J.
It sounds like you are constructing the continent table on the fly
rather than storing the information for it as you obtain it. What I would do
is to have an array (an instance field) in my MapGrid indexed by the
continents, with the capital and size of each continent. Then the
continentTable method would just be assembling the data from this
array into a String. Alternatively, you could have the method
run a for loop over the continents, looking up the capital and
centrality for each. (You should know how many continents there are in all
after running markBlobs or its equivalent.)
highLargestConts, how should I break ties between MapGrids?
The winner should be the MapGrid that comes from the lowest seed. But since that rule wasn't in the specification, we won't take off credit for making a different decision. (As opposed to the case in Question 4.4 above, where we would take off something for choosing the wrong capital.)
There are various things you could do, and anything using
lists is ok by us. The simplest thing is to put all the MapGrids in the range
into an unsorted list, and then use an iterator to look at each one in turn,
remembering the highest and lowest you've seen according to the measure you
are looking at. You could write a compareTo method and use a
sorted list, but unless you use Comparator objects, which we
haven't covered in class yet, you can only sort by one of the two measures.
Last modified 30 October 2012