|CSE Home||About Us||Search||Contact Info|
A. There will be weekly reading assignments, and you will generally be expected to answer questions about them on a course discussion board ("The Blog"). See next question for more on how they are graded. Additionally, there will be programming and/or written assignments about every other week. Assuming you demonstrate mastery of the basics on 3/5 of these, you can expect a grade in the B range (2.7-3.3). Similar work on 4/5 should give you a grade in the A/B range (3.2-3.6); 5/5 => A- (3.5-3.8). "Mastery of the basics" allows room for some details or corner cases to be wrong, but you've got the basic point of the assignment. Excellent work (details are generally right, extra care with the tricky bits, lucid explanation of results etc.) and/or some of the extra credit points can boost those ranges by a few tenths. Based on this, I'm expecting the class average to be 3.5 or above, but there's no "curve"; if everyone digs in and does the work, I'd be happy to give everyone a 4.0 (and if no one does, ...)
A. You are expected to have read the assigned papers/text book sections for the class before the class meeting; the material is complex enough that you will fall quickly behind if you are not prepared.
This quarter we will be doing things a bit differently than you might be used to. Instead of asking each of you to write a summary for each of the papers over the quarter, the class will write a collective review for the reading in this course.
How this works: by 5:30pm on the day of each class, please log onto the message board web site (note you'll need your UW-NetID login and password), read the prior posts for that week, and then add some useful comment to the threads for that week. Typically there will be one thread per paper and section of the book. The comments you post can/should be brief -- e.g., just a couple sentences -- that adds something to the ongoing discussion in that thread. Examples include: the main idea of the paper, a list of pro's, a list of con's, an example of why you think the approach would/would not work, a flaw in the evaluation, a comparison to some alternate approach, a pointer to some followup work you found on the web, an application of the idea that's now in practice, potential cross-fertilization with other areas of Computer Science. Try to avoid simple "me too" posts; we're not voting. "I agree with X because..." or "I (politely) disagree with X because..." are perfectly fine.
Prior to class, make sure to read the rest of the blog.
Your posts to the blog will be lightly graded, using a zero, check, check+ scale. As long as you say something that has some detail in relation to the paper, that's worth a check. A post that says simply, "Me, too" or "I was confused," unamplified, will be given a zero. Check+'s are given to people who do more than just post a summary of the paper and contribute to the discussion. This can include raising a question or resolving a previous poster's question or confusion. Relating the paper to a current or past project will also merit a check+. Posting links to other papers, powerpoint slides, etc. also earn the bonus, as will addressing explicit "extra credit" steps laid out in some of the assignments.
A. In general, I want assignments completed and turned in before the start of class on the assigned date. The occasional assignment turned in a day or two late is not a problem, but I will start deducting points beyond that. Contact me if you get in a bind this way.
A. EC really isn't about grades; it's there to give you a semi-structured way to dig deeper into the material if you're interested. That said, I do factor it into grading just to give a little recognition, but I always set my grading curve before I look at anyone's extra credit, so it doesn't become a back-door requirement: other people doing extra credit when you choose not to should never lower your grade. Also note that extra credit is not graded in a "linear" way; some options are harder than others, but twice as much work doesn't necessarily mean twice as many points. Also, grade-wise, I weigh the basic homework assignments more heavily; you'll need lots of extra credit to make up for skipping an assignment.
I usually give several EC options. You can do none, one, or more of them. You can do something else, too, if you want, but it's probably a good idea to run it by me first.
You should always include a very explicit description of what you did for extra credit, e.g., include a file or folder labeled EXTRA-CREDIT with electronic turnins, so that we don't overlook it. As part of it, outline what you did, why you think it was an interesting thing to look at (especially if you made up your own or substantially modified or needed to flesh out many details of one of my vague suggestions), and what lessons you can draw from the exercise. Enjoy!
A. There's a tension here. I want this to be a learning experience for you, so if you want to use and learn about some new language/framework/package/tool, that's good. On the other hand, if it results in code that we can't grade, that's bad. In general, we have adequate fluency in C, C++, C#, Java, Perl, Python, R and Ruby on Linux, Mac or Windows that we can read and run your code, but the farther afield we get, the harder this becomes. Potentially running it becomes especially hard if we have to download and install (then uninstall) lots of pieces, and impossible if it's commercial/proprietary. Nevertheless, if you want to use something out of the ordinary, ask; we may be able to accommodate.
Two additional issues are relevant. First, note that there is code "out there" to solve many of the homework problems. You should avoid it, and write your own. Some of these gems are embedded in very useful frameworks (BioPerl, etc., ...), which you are free to use; just avoid the core of the assignment. E.g., if the assignment is to implement the Smith-Waterman sequence alignment algorithm, you may use BioPerl to fetch sequences, or whatever, but don't steal their Smith Waterman code. Second, choice of language: some of the homework assignments will involve moderately compute-intensive algorithms. I don't think this will be a serious obstacle, but interpreted languages might make your development/debugging of these programs somewhat painful, so do some exploration of this before you get in too deep.
Computer Science & Engineering|
University of Washington
Seattle, WA 98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX