My Adventures with COSI TAs
Maintained by Jonathan North Washington and Ian Adams
Contents
Wrong Book on Reserve
The first written assignment in the class was given to us as a couple problems and a list of problems that were supposedly to be found in the textbook. The textbook was on reserve in the science library, and I'd ordered mine online and it hadn't arrived yet, so I went to the library and xeroxed a couple pages of their copy.
When my textbook arrived a week later--after I had turned in the problem set--I noticed a few difference between it and the one on reserve in the library, yet they were supposedly the same edition of the same book, with the same ISBN number(!!). I also noticed that one of the problems that I'd done was differently numbered in the two editions. This bothered me. I posted to the newsgroup about this to inform the TAs and prof of the problem (mentioning that I was concerned that I may have done the wrong problem), and a TA responded that the correct textbook was in the library, that it was our responsibilty to have the correct textbook, and that we could check with other classmates who had the correct textbook to make sure we did as well.
When I got my assignment back yet another week or two later, graded, I'd lost all the possible points on one problem (the one that was misnumbered), with a comment from the TA/grader saying I'd done the wrong problem. When I brought up the issue with the textbook in light of my grade and this comment, they said that I should redo the problem and submit it to them within 24 hours. I did this. Then they said that I was supposed to've just resubmitted the assignment, and they'd've graded the problem that I did as if it'd been the right one. I did this, and it worked out fine.
Indeed, the copy of the textbook in the science library had been the wrong copy after all, despite being on paper the same exact version I had ordered, to the ISBN number. And yes, I ordered the correct version, but a handful of people in the class had not (oh well), including Ian. Several times throughout the class, not only did he end up borrowing my textbook, but I ended up borrowing his; read on.
Assignment as a Word Document
In response to above incident, the TAs decided to scan the questions from the book and post the next assignment (PS2) on our class website. In Word Document format! WITH THE QUESTIONS AS IMAGES! Ian found the assignment first, and was shocked into converting it to pdf and putting it in his personal webspace, forwarding the url to the entire newsgroup.
A few days later, the professor e-mailed Ian, CCing it to the TA, thanking him for posting the pdf, and asking the TA to copy the pdf over onto the class webpage, and to post all future assignments in pdf format. The copy of the assignment on the webpage remained in .doc format.
Wrong Version of the Java Compiler for Grading
written by Ian Adams
The TAs, in explaining the requirements for the programming assignment, explained that the submissions were to compile in the latest version of Java at Brandeis, namely, the one on all of the machines in the Berry Patch. We were warned that other machines, not physically located in the Berry Patch, might not have the correct version, but rather an earlier one.
Ian wrote code that compiled and ran on a Berry Patch machine, under the latest version of Java, and submitted it confident that there were no (major) bugs. A short while later, he recieved an email from one of the TAs, saying that his code didn't compile. He did include the compiler errors in the email, and by looking at them and the APIs of the versions of Java available at Brandeis, Ian concluded that the problem was that the compiler could not find methods only present in the later version of Java. He responded to the TA, asking where the TA had compiled, and that the code did indeed compile on a Berry Patch machine with the correct version of Java.
The TA confessed to having done the testing on a non-public machine, one which was not in the Berry Patch and one which had the earlier--rather than the correct--version of Java.
Problem Set #3
Problem sets, in general, have been assigned on Wednesdays, and due the next Wednesday. PS3 was scheduled to be released on Wednesday, the 13th of October. It was not released that day. In class the next day (Thursday), the professor promised that the problem set would be posted later that day, and gave us an extra day to do the assignment, so that we would still have an entire week. It was not posted Thursday. At 1:10 A.M. on Friday, the third problem set was posted as a .doc file. I posted to the newsgroup so that they'd change the "Out" time to Friday. I then got an e-mail from the original TA in response to my first e-mail, saying that I should raise all of these issues with the professor. An hour or two later, another TA--one not yet involved in these adventures--posted the problem set in .pdf format and fixed the "Out" time to reflect the fact that it was actually posted on Friday.
The second question on the problem set was one scanned in from the book. This question asserted that, in the section of the chapter where disabling interrupts was suggested as a means of synchronization, that doing so could have an effect on the system clock. The section of the text had no mention of the system clock. The wrong version of the book had an identical question, except that the numbers (including the number of the section in question) were changed. This version did have a brief mention of the system clock that was not present in the correct version. The book contained an incorrect assertion about its own content, resulting in content needed for the question not being present in the correct book. The TAs did not pay close enough attention to the question they assigned to catch this beforehand.
To Be Continued...
The Final Programming Assignment
Ian and I submitted our final programming assignment for the class a minute and a handful of seconds before it was due. We tried to follow the spec as closely as possible. Many of the ways we implemented things, however, ended up having to specifically contradict the spec, since the spec itself was contradictory. We pointed these problems out in the README, as directed by the spec. When we turned in the physical copy, the README was the very first page.
When we got an e-mail announcing our grade as 60/100, we were concerned—we were pretty sure we'd submitted an assignment which would receive more credit than that. We responded to the TA who had graded our assignment, asking what we'd lost points on specifically. He got back to us soon, informing us that he'd gone home for winter break already and had left the grading rubrics on campus, but he sent us a blank copy of the rubric by e-mail as a reference and said we could talk with him the next semester.
So we come back from break and e-mail him again. He said he didn't have office hours this semester since he wasn't TAing, but he'd send the rubric to me by campus mail if I gave him my mailbox number. I did and the next time I checked my mail I had a copy of the rubric. Ian and I looked over at it.
Of the 40 points we lost, 30 of the points had to deal with the same issue. The spec said the following:
You will use the free list space management technique discussed in your textbook (12.5.2). More specifically, each block of the free list contains Disk.POINTERS_PER_BLOCK block numbers, where POINTERS_PER_BLOCK = BLOCKSIZE/4 (4 is the size of an integer in bytes). The first of these is the block number of the next block on the free list. The remaining entries are block numbers of additional free blocks (whose contents are assumed to be meaningless). While the system is running, you will want to keep a copy of the first block of the free list in memory.
So it made reference to something in the book that described how it was to be done, and they elaborated further upon it, saying specifically what they wanted. Or so it had seemed. Apparently what is said at that point in the book is a completely different system (where freelist just contains the address of the first free block, which itself has a chunk set aside which points to the next free block, etc). If one implements the freelist the way stated by the spec, it's bigger than they'd apparently anticipated, and so the number of blocks often must be changed to compensate.
This was so in three of the test programs they ran on our filesystem. We'd pointed out—very explicitly—in our README that for these tests (and others like it), one must add 1 to the number of blocks in order for the test to work.
That's right—we lost 30 points because we'd implemented something the way they'd told us, even though they hadn't meant it that way, and because the value of a variable was off in their test/grading programs by 1, even when we made it very clear (if they'd bothered to read the README which we were required to submit) that they'd have to change that because of the conflict which we ran into on implementation.
How were we supposed to know that the reference to the implementation from the book that they'd given us wasn't a typo? Especially when they'd described very clearly a different system which is also mentioned in the book, and which they'd talked about in class (and which in some ways is a better implementation)....
