Assignment 4

Due Sep 21 on line

Part of the homework for CS:2820, Fall 2020
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Machine Problem 2 -- due Monday, Sept 21.

make the input handling on the Epidemic model bullet proof, so that stupid things like an input file with lines out of order, or stupid values (for example, negative populations or household sizes) or things that don't scan do not cause exceptions or nonsense results. The should get sensible error messages for these. It's interesting how much code it takes to do this, even for a small problem. To minimize the excess code, you should try to use appropriate helper classes for error handling and to help scanning.

Also, add a new field to each person: infectionState. This should be able to take on the values uninfected, latent, infectious, bedridden, recovered, and dead. All newly created people should be uninfected except for a number of people determined from a new item in the model description file that gives how many people are initially infected. This model description file illutrates the new item:

pop 25 ;
infected 3 ;
house 3 , 1 ;

Notice that the input could just as well be like this:

house 4 , 3 ;
infected 2 ;
pop 12 ;

Furthermore, it would be nice to allow comments. How about Java style comments that run to the end of line like this:

house 4 , 3 ; // this is a range from 1 to 7

If you are happy with your solution to MP1, feel free to base your work on that, but you are welcome to use any working solution to MP1 as the basis of your solution to MP2, so long as you preserve the author attribution in the comments. Oracle's Java documentation standards say that authors should be listed in chronological order, so add your author tag after whoever you got the code from.

Note that a working solution to MP1 is available on line.


Your code must be in a single source file named the CLAS Linux system. This implies that the main method is in a class called Epidemic. To submit your solution, use the following Linux shell command:

~dwjones/submit SECTION

Where SECTION is the section number you are registered in, which must be one of 0A01, 0A02, 0A11 or 0A12.

Coding Conventions

Looking at the submissions for MP1, many completely ignored what was said in class about lines longer than 80 characters long. They get unreadable very quickly. Many students seem to enjoy putting in lots of blank lines at the top and bottom of the file, or large blocks of blank lines between methods or classes. Don't do this! It makes it much harder to read the code when you can only see a few lines at a time. 8-space indent steps runs code off the screen very quickly. Oracle's Java style guidelines say use 4-space indenting for a very good reason.

The following little shell command can help you avoid some of these sins:


It checks for and shows you all the over-length lines in your file, it checks for blank lines at the start and end of the file, and it remarks about odd mixtures of tabs and blanks that can interfere with editing but are invisible on your screen. It does not know anything about Java. It does not check your comments or your intenting.

Also, a surprising number of students omitted any header comments on their code claiming authorship. That is not acceptable. Judicious use of comments is important!

Grading Criteria

If it compiles and runs on our test files, we will look at the source code.

Questions and Answers

A student asked: How do we organize our solutions, as just one source file or multiple files?

Still just one file, named, with public class Epidemic holding its main method.

A student asked: Does infectionState require a new class?

The obvious Java data type to use is an enum. Note that the simplest form of infectionState would be a boolean. That is, a person would either be infected (true) or not (fase). The predefined data typ boolean is a good example of an enum. If this was not predefined, you cold define it with this:
public enum boolean { false, true }

Note that the infeciton declaration could look just like the above, but with a longer list of possible values.

Reading the assignment closely, each person has an infection state, so for the requirement to print out the population, it makes sense to print out for each person, not only their home but their infection state. Nothing in the assignment asks you to print out a list of all the people in each infection state. Infection states aren't places.

Ultimately, in the simulation, we will need to count the number of people in each place who are contageous or bedridden, because that count is part of determining the likelihood that an uninfected person will be infected when they enter that place.

A student asked: Should we assign infection states randomly over the range from latent to dead?

Note that the only two relevant infection states for the purpose of initializing the populatio are are uninfected and latent. The latter is the initial state of an infected person. As the infection progresses, it will go through other states. Later, when we start simulation, we will need the other states.

A student asked: Is it OK to just infect the first n people created, or should the initial infection be randomly distributed through the community.

This is the kind of question that is very typical of the early stage of the development process. The folks who wrote the specification never imagined issues of what was algorithmically easy, so it never occurred to the to specify something like this. Now that you notice this, note:

Which is right? It is unlikely that the folks who wrote the spec (me) were asking for initial infections to be lumped in just a few families. For an infectious disease, infecting one person in a family frequently infects the whole family a short time later, so this is an unlikely interpretation of the specification. So, it is better to spread the initial infections more or less at random over the population.

A student asked: If we mix your code with ours, how do we credit who did what?

Bare minimum requirement: The program header must credit both of us. If you take my solution to MP1 and add your code to make it solve MP2, then credit me first, you second.

In more detail, as the blending of code gets more complex, it becomes appropriate to add @author tags to the Javascript comments on individual classes or even on individual methods. Any class that's 100% your code should have just your tag, while classes of mine that you modified can have both tags, and classes you didn't change just have my tag.

A student asked: How scrambled can the input be?

If someone writes 25 pop instead of pop 25 don't try to make sense of it, it's just completely wrong. On the other hand, it must not throw an exception. It might say something like unknown command: 25 and then go on from there. Don't write massive code trying to make sense of wrong input.

A student asked: For incorrect or nonexistant files, can we throw an exception or must we provide a default value?

Neither! There is no obvious default value. Your program must output an appropriate error message and terminate gracefully indicating that it is a failure. You can only do this with a call to System.exit(1) (actually, any nonzero value will suffice, and the value 2 is historically associated with the "no such file" message). You may throw an exception internally to handle this, but you must catch it. The default behavior of Java for unhandled exceptions is unacceptable.

A student asked: Should the program always exit when it encounters an error? latent to dead?

I talked about this in lecture. We have two error handlers in the code I included in the lecture and posted on line last week. Error.fatal() outputs a message and kills the program on the spot. Error.warn() allows the program to stumble onward.

We will talk later about killing the simulation if there were warnings. For now, syntax errors in the input file should be handled with warnings. You might look at the bug messages in my code though for a suggestion that if there are too many warnings, perhaps the code should give up instead of outputting a cascade of messages.

A student asked: The assginment didn't say to include infectionState in the output.

You need to recall the purpose of the output. Until we build a working simulation, the only purpose of the output we are creating is to debug the model. How can you know how well you have assgined the initial infection state if you do not include this in your dump of the population? So, when you print out the collection of people, of course you need to include not only where each person lives but their infection state.

A student asked: What about the difference between "5;" and "5 ;" -- the issue of spaces before punctuation marks.

As discussed in class, it would be nice to get rid of this space, but to do that nicely, we need to explore deep things inside class Scanner. Until we do so, it is not worth the effort.

A student asked: What kind of error messages are appropriate?

Error messages should be brief but helpful. I recall one piece of software I I used where the only error message was "?". This was not very helpful. I recall other software that had the anoying tendency to produce miniature essays on the nature of each error. That was annoying because it tended to belabor the obvious.