The homework will consist of both programming exercises and written questions. This handout describes some general thoughts and techniques for doing homework, as well as what is required, how to submit it, how late homework is handled, and other administrative matters.
All homework is due at 11:55PM on the due date, unless noted otherwise on the assignment. These will be graded and comments returned to you as quickly as possible; I'll try for three class periods, but can't guarantee it.
For written homework, you must turn in an ASCII, a PostScript, or a PDF version of your answers (you can use any text processor you like to generate these). Please do not submit Microsoft Word files; since I may grade these on UNIX-based and Linux systems, I might not be able to read those files. If you submit PostScript, please be sure the file will print on our department printers (use ghostscript or gs to check this; if it displays the file properly, the file should print correctly). If your file is a PostScript file, please choose a name that ends in ".ps". If it is an ASCII file, please choose a name that ends in ".txt". If your file is a PDF file, please choose a name that ends in ".pdf".
For programs, turn in the source code, Makefile (you must include one) and any related information (such as man pages and README files). Bundle these into a tar(1) file, and submit it. If the file is an uncompressed tar file, choose a name that ends in ".tar". If you compress the file using gzip(1), choose a name that ends in ".tgz". Be sure that I can recompile the program without errors by typing "make". As I will grade them using systems in the CSIF, please check that your programs run on one of the Linux systems there. You are free to use any programming language that is available on the CSIF and that I can get to (but I prefer C, C++, or a UNIX scripting language such as sh(1)).
Please turn in your written exercises and programs electronically through MyUCDavis. Do not use the handin program! If you need to turn in something on paper (for example, a diagram that you can't draw using your text processing program), please hand it to me before the assignment is due, and put a note in what you submit electronically that you have done this. (That way, I will know to look for something written, rather than mark you off for that problem.)
When you are asked to analyze something, or explain something, please be complete, and show your work (including any commands you give, and their output, to show how you did the problem). Otherwise, even if you get the right answer, you will get ZERO (that's 0, zip, nada, rien, nothing) points. Think your answer through and do a rough draft. Students (and professionals, actually) often overlook this, but it is vital. Write clearly and cogently. If the question asks for an opinion, state your opinion clearly, justify it, and don't ramble. Answers that start, "My opinion is yes ..." and conclude with "... on the other hand it could equally well be no" won't get much credit.
Please do not leave assignments for the last minute. The assignments are non-trivial and will require significant design time before you start programming and debugging. When I decide on the due dates, I assume you will spend significant amounts of time on design as well as coding and debugging. If you choose not to do this, you will have difficulty finishing the assignments on time.
Please take the time to design your program carefully. More programming problems arise from improper design than anything else, and the few hours you spend on design will be amply repaid by shorter coding and debugging phases. So please think the design and interfaces through, and--as always--try to find the simplest way to do the assignment (within the limits given in the assignment, of course)!
I do not mind being asked for help; indeed, I welcome it because it helps me know what students are finding difficult or confusing, and sometimes a few words about the problem in class will clarify the assignment immensely. I do mind being asked for help before you have tried to think the problem through. The classic objectionable question (this really happened) occurred on a homework assignment in which the class was given a buggy program. The assignment said the program did not work, and the homework was to debug it and make it work. That particular class period discussed how to deal with bugs, and gave tips and techniques on how to debug programs. Within 10 minutes of the end of the class during which the assignment was given out, the instructor got this request for help: "The program doesn't run. What do I do now?"
So, before asking for help, please be sure that you have:
When you come to me, or send me a note, asking for help, please show me whatever you have done to solve the problem, because the first question I will ask you is "What have you tried?" This isn't because I think you're wasting my time. It's because understanding how you have tried to solve the problem will help me figure out exactly what your difficulty is and what I can do to help you. Remember, I will do everything I can to avoid solving the problem for you. When I give you help, my goal is to help you solve the problem yourself.
When I grade your homework, I look for simplicity, clarity, elegance, and documentation. Here's a rough weighting of the various factors that go into the grade of each programming assignment:
| Correctness | 60% |
| Commenting, ease of reading | 20% |
| Clean, readable output | 10% |
| Documentation (README, man page, etc.) | 10% |
You can turn in your homework up to one class period late (unless the assignment says otherwise). If you turn it in late, I will grade it normally, and then deduct 20% as a late penalty. Requests for exceptions will be handled on a case-by-case basis; please do feel free to ask!
If you feel that there is an error in grading, please come see me and I'll look over it (and possibly talk with you about it). However, don't dally; any such request must be made within one week of when the grades were made available. After that, I won't change your grade.