# Assignments, Exams and Overall Grade A student's overall grade is computed from the following components: * 65% of the grade is taken from the 8 assignments in CS 24. Each assignment is weighted equally. * 15% of the grade is taken from the midterm. * 15% of the grade is taken from the final exam. * 5% of the grade is course participation. The course participation points are somewhat less defined than the standard assignment points. Anything that indicates that you're "involved" in the course and trying to learn will get you points for this section. Examples include (but are not limited to) completing diagnostics in lecture, going to office hours, and providing useful, constructive feedback for the course. Our goal for the participation score is to make your grade reflect the *effort you are putting in*. Specific assignments or exams may be curved when deemed appropriate. However, this happens very rarely, as average grades on assignments tend to be pretty high. Generally, 90%-100% is an A (specifically, 90%-93.33% = A-, 93.33%-100% = A), 80%-90% is a B (80%-83.33% = B-, 83.33%-86.67% = B, 86.67%-90% = B+), and so forth. According to the Caltech Catalog, students on Pass/Fail will pass for a grade of D or better. Thus, if you are taking the course Pass/Fail and have at least a 63.33% (D) grade in the class, you will receive a Pass. Note that we will only give A+ grades for students that are regularly meeting or exceeding the highest expectations in the class; i.e. doing extremely well on all assignments and exams, and also having a very high level of participation in the class. Just earning an overall score \> 96.67% will not automatically guarantee an A+. (Historically. only 1-2 A+ grades maximum have been given in any given term.) Grades for seniors and graduate students are due 1 week earlier than the grades for other undergraduates. **However, seniors and graduate students are still expected to complete all assignments and exams that are part of the class.** To facilitate this, HW8 and the final exam are made available early enough for all work to be completed in a timely manner. # Programming Environment **All assignments must work properly on the 64-bit CS24 Linux VM image.** (The one caveat is that we will try to support the 64-bit Linux CS lab machines.) Students should use the Caltech CS lab to do their assignments, or make sure they are working an appropriate system to complete their lab work. You are free to use other 64-bit Linux systems to do your work, but you should at least test on the CS24 VM image to make sure your code works when your assignments are graded. There are many technical reasons why we have this requirement. We have previously tried allowing students to complete assignments on any platform they choose, but there are subtle incompatibilities between 32-bit and 64-bit platforms, and between how different operating systems compile and link the exact same program. Additionally, a number of labs depend on low-level Linux system APIs that are not provided on MacOS X or on Cygwin. Requiring a single platform simplifies the lives of both the students and the graders. # Textbook The **optional** textbook for CS24 is "Computer Systems: A Programmer's Perspective, 3rd edition" by Randal E. Bryant and David R. O'Hallaron. **This book is optional for the course**, although students will certainly benefit from the material in this book. Copies of essential material (homework problems, etc.) will be provided to students. For students that have access to the textbook, the optional reading assignment specifies the parts of the book that are relevant to that week's material. # Collaboration Policy Students are allowed to work together when developing the approach to assignments. However, your submission must be entirely your own; you must write up your homework and lab work without referring to any material developed with others. **This includes pseudocode and other specific architecture/design notes.** If an assignment question specifies that the C compiler can or should be used to generate x86-64 assembly code, feel free to do so. Otherwise, you should assume that the compiler's assembly output is off-limits as a reference for writing (or reverse-engineering) assembly code for homework or exam problems. The rationale is pretty straightforward: it's like having a reference-solution written by a very intelligent and clever (and well-verified!) assembly language programmer. If this programmer were a human being, it would be an obvious Honor Code violation. Similarly, for assignments that ask you to write some common facility (e.g. the heap allocator in HW3), you may not reference existing allocator implementations. Again, if the author were in CS24 it would be an obvious Honor Code violation. You are always encouraged to help each other if you have trouble with the software tools used in this course. Help with debugging is also encouraged; many bugs are resolved very easily once a fresh pair of eyes is involved. However, don't let help with debugging stray into writing code with other students; you should write your programs entirely by yourself. **Important guidelines:** > **Do not** "help" other students debug their work by showing them your code. > Help them by looking at their code and figuring out what is wrong with > it. If you have had other classes that use the "50-foot policy," this > is effectively that policy: Help others with your *eyes*, not your > *code*. > **Do not** share code with other students through electronic means (e.g. > through email, instant messaging, or pastebin/gist-like services, etc.). > This makes it too easy to copy another student's code. Historically, > problems have emerged when students engaged in this kind of behavior. You may use the Internet for **reference material** (Intel processor manuals, C language documentation, API documentation, etc.). You may use the material you find to develop your understanding, but again your submission must be entirely your own. You **may not** search the Internet for answers to homework or exam problems. You **may not** ask others on the Internet (e.g. on stackoverflow-type forums, "do my homework" type websites, etc.) for help solving homework or exam problems. You **may not** reference the work of past CS24 students. You **may not** reference past solutions. **If you run into any questions on the collab policy, please ask Donnie or Adam.** [Note that the onus is on the student to contact the teacher when there are questions about Honor Code issues](http://donut.caltech.edu/about/boc/UGHSHB_main.html#Philosophy) (see paragraph 5 in this section). **Don't just guess.** Summary: For homeworks and labs, you may use most resources at your disposal, but everything you submit must be developed and produced solely by you. # Due Dates and Late Policy **Assignments** specify their due-dates on the course website. Generally, assignments are due on Thursdays at 2:00AM. Exams may specify a different due date; in particular, the final exam is usually due at 5:00PM. **Late assignments and exams will be penalized**, based on how late they are submitted: - Up to 24 hours (1 day) after the deadline: 10% of the points are deducted - Up to 48 hours (2 days) after the deadline: 10 + 20 = 30% - Up to 72 hours (3 days) after the deadline: 10 + 20 + 30 = 60% - After 72 hours, sorry, no credit. We will usually grant a grace period of up to 3 minutes when assignments are slightly late, primarily because different computers do sometimes have slightly different clocks. (However, you should use a time server to keep your computer's clock accurate.) Anything beyond this is likely to be counted as late. If you have a note from the Health Center or the Dean's Office, Donnie and Adam will often grant extensions. These extensions will not consume late tokens. Additionally, if you encounter some other extenuating circumstance, you should talk to Donnie or Adam and see if an extension might be warranted. **Every student also has 4 "late tokens" to use in whatever way they see fit.** Each late token is worth 24 hours of extension, and they can be used on assignments or exams. To apply late tokens to a particular assignment, update the file named **tokens.txt** in your submission, specifying how many late tokens you are applying to that submission. **Ditch Day** invariably falls during third term, which means it has a significant chance of affecting CS24. - If Ditch Day falls on a Monday or Tuesday, no blanket extension is granted. - If Ditch Day falls on a Wednesday, then this would clearly affect the CS24 due-date (due to stacks where students don't get back to campus until the next day), and there would therefore be an extension. - If Ditch Day falls on a Thursday, then this would clearly affect the CS24 due-date (due to general excitement and buzz around campus), and there would therefore be an extension. - If Ditch Day falls on a Friday, then this would not affect the CS24 due-date, as the CS24 set should have been turned in nearly 24 hours before "Ditch Day Eve" when underclassmen are advised to skip their homework and go to bed early. So no extension should be required. We will send a notification of the extension out during (not before!) Ditch Day. Seniors taking CS24 can have up to 4 additional tokens to use for the assignment(s) affected by Ditch Day, since they generally work very hard during the time leading up to Ditch Day. Just make a note in your **tokens.txt** file stating that you're a senior working on Ditch Day, and how many extra days you needed. # Office Hours CS24 is a challenging class, and we strive to be available as much as possible to help you through the inevitable bugs and difficulties you run into. However, we do have a certain base expectation of students taking the class: * **You should have a general proficiency with the C programming language.** TAs are not required to teach students C from scratch. TAs will gladly explain more advanced concepts in C or in IA32 assembly when necessary. Feel free to take advantage of the tutoring program run out of the Dean's Office, if you would like some help learning C better during the term. * **You should be learning to debug your own programs.** Frequently we see students who complete assignments in 3-4 hours, and other students who take 15-20 hours to complete the exact same assignment. One major difference is usually that the fast student is better at debugging their program than the slow student is. However, debugging is definitely something that a person can learn over time, and CS24 is an excellent opportunity to develop those debugging skills. You should review the debugging lectures that we provide as part of the course material. Additionally, feel free to talk to us about appropriate debugging strategies for the various assignments you will work on. * **When you go to Office Hours, you should not expect the TAs to identify all of your bugs for you; you should have already tried to do that.** It will be a much better use of your time, and the TA's time, if you have already spent time looking for your bugs. Using assertions and having well-commented code will help you identify bugs more quickly. If you need any guidance on how to use assertions, or any other aspect of writing good code, we are more than happy to help. Of course, if you have been trying to track down your bugs and you are completely stumped, we will do our best to help. In general, **program-debugging help will be the lowest-priority task for Donnie, Adam, and the TAs at Office Hours**; answering quick questions and clarifications may preempt such debugging help. In general, Adam, Donnie and the TAs will endeavor to help as many people as possible in the time constraints of Office Hours. # Grading Guidelines All written assignments and labs will include style grading. The basic rule of style is that any answer, proof or program should be concise as well as complete, containing no more and no less information than necessary. For example: * Submitting a program with no commenting will result in a significant penalty, but submitting a program with so many comments that the program is unreadable will also result in a penalty. Comments should aid in the understanding of the program, not distract from the program. In particular, you should avoid writing comments that simply mirror the code. Instead, state the higher-level purpose or intent of the code. Additionally, anything that is particularly complex should definitely be explained in comments. Finally, every function should have a comment-header describing the purpose of the function, its arguments and return-values, and any details important for using the function properly. * When assignments ask for answers or explanations to questions, your answer should completely and concisely state what the question is asking for. The general rule is that a person versed in the topic (for instance, the TAs) should be able to understand your answer with a minimal amount of effort, and it should be clear to us that *you* understand the answer. Make sure you use terminology correctly. Words have meaning, and if you want to be understood, you need to learn the terminology of the topics you are studying. If you use terms incorrectly in your explanations, we won't have any choice but to deduct points. The programs that you write must also follow a good coding style. In general, you should always match the style of the source code you are given. Here are some additional guidelines: * For C programs, you should follow Mike Vanier's [CS11 C Track style guide](http://courses.cms.caltech.edu/cs11/material/c/mike/misc/c_style_guide.html). Make sure to review this entire document and follow it carefully. **Why do we care about style?** There are two main reasons. First, as you gain experience in the field, you will begin to work with others and it is important that they understand you. Second, we have more difficulty grading your work when we have to wade through hand-waving. Unnecessarily convoluted solutions are often a sign you are missing the key ideas for the assignment, and will usually lead to point deductions.