@mjgraing: "Hello,
The A3 autotesting e-mail went out last night, and it has the following tests:
#### Test with -1 players
- SHOULD BE A USAGE MESSAGE
#### Test with 1 players
- SHOULD BE A USAGE MESSAGE
#### Test with 21 players
- SHOULD BE A USAGE MESSAGE
The assignment specification says the following:
<quote>
The assignment defines what it means for the number of players to be a 
"valid" integer value (between 2 and 20), and then tells us to assume 
that it will be in that range.  So why, then, did the autotests expect 
us to be checking for invalid input and handling it?
(Before you ask, I am well aware of the assignment re-marking policy; 
the purpose of this message is to help me understand why these tests 
were included before going to the trouble of making an appointment with 
a TA.)
Morgan Grainger
4B Computer Science"
    @aroegies: "<quote>
I read valid integer value, as meaning that n is an (presumably signed) 
integer as opposed to say a double. Thus allowing usage of various 
integer tools (i.e. tools to say go from a string to int). The bounds on 
  n signify a constraint rather than what constitutes a valid integer. 
This is the way I took it anyways."
    @mjgraing: "On 2009-02-12 11:12:56 -0500, <email_address> (Peter A. 
<quote>
I'm sure that that's what you meant, but you didn't say it very 
clearly; given that, using the word "misinterpreted" is inappropriate, 
since it implies that any reading of the assignment other than what you 
intended is incorrect.  If I had realized that the specification could 
be interpreted the way you describe, I would have asked on the 
newsgroup, but it seemed quite clear to me that you meant what I 
described above.
Testing invalid input when the assignment could reasonably be 
interpreted to say that valid input could be assumed doesn't seem 
reasonable, and it certainly doesn't teach anything useful about 
concurrent or parallel programming.  You really need to remove those 
test cases.
Morgan Grainger
4B Computer Science"
    @aroegies: "<quote>
It may have nothing to do with concurrent or parallel programming but it 
  has to do with good programming style, which is what Prof. Buhr is 
trying to teach us. That being said, Prof. Buhr did provide a sample 
executable and presumably one would at least use that to ensure one's 
program handles error cases in a similar manner."
{'source': 'USENET', 'other_information': '{"reply_count": 3, "forum_name": "uw.cs.cs343.20140403.mbox"}', 'file': 'data/output/usenet-uw.cs.parquet'}