None. However, CS 1 is strongly recommended as a prerequisite.
You must have a CS cluster account to submit assignments (an ITS or UGCS cluster account is not acceptable). To register for an account on the CS cluster, please go fill out the online form: http://www.cs.caltech.edu/cgi-bin/sysadmin/account_request.cgi. If you have not already done so, please do this immediately as it will take some time to process and you will need your account for the first assignment. You need to be at least somewhat familiar with Unix (specifically Linux) as well; if you aren't then you can read this tutorial at ITS. The CS cluster computers are located in room 154 of the Jorgensen building; the combination to the room is "secret", but can be obtained from me by request (or by coming to the first lecture).
The instructor is Mike Vanier (mvanier@cs.caltech.edu). My office is in Jorgensen room 154a. My secondary office is in Beckman Institute room 344. These days, I'm usually in my primary office.
My office hours are on Mondays from 4 to 6 PM in Jorgensen room 154a.
However, feel free to drop in to my office at any time. I'm unlikely to be in in the mornings, but I'm often around fairly late at night. If you need to meet with me outside of office hours, sending me email beforehand is strongly recommended.
Lectures will be held on Wednesdays at 9 PM in room 74 of the Jorgensen building.
You will need card access to the Jorgensen building. If you haven't already given me your Caltech UID number (on the signup sheet or by email), email me your UID number and I'll arrange this. If you wrote it on the signup sheet it shouldn't be necessary.
Lectures will typically last half an hour to 45 minutes, but may go longer depending on the needs of the class. Attendance is optional; if you can do the work without lectures (which is typical for this track), it's fine with me.
The course is pass-fail. I will grade each assignment on a scale of 0 to 10. All assignments are due one week after they are assigned. Late assignments will lose one mark for each day they are late (all the way to zero). If the assignment doesn't meet my standards, I will require you to redo it (see below).
The specific day that an assignment is assigned will be indicated on the grades page. Usually, it will be on the same day as a lecture. All labs are due at midnight of the due date.
In special cases, I may grant extensions on homework to individuals in special circumstances. The duration of the extension will depend on how compelling the reason for the extension is.
There will be seven labs, for a maximum total mark of 70. The pass grade corresponds to an average grade of 7/10 on all labs, or 49/70. If you get that grade without having completed all the labs (i.e. you got 10/10 on the first five labs), you don't have to complete the remaining labs, but of course, you'll learn more if you do (and you will need to complete all labs to be eligible to be a CS 11 TA in this track in the future).
If you're heading for an F and drop day is near, I will encourage you to drop the course so as not to damage your academic record. If you have more than two assignments that haven't been completed satisfactorily by the time I have to submit the grades, you will get an F. If you have only one or two incomplete assignments I may give you an E instead, but you will have to complete the assignments as soon as possible (generally by the next Add Day, except for after the Spring term).
We have two teaching assistants this term: Brent Goldman and Mark McDuff. Brent's email address is: brent /at/ caltech /dot/ edu (figure it out). Brent's office hours are from 2:30-4:30 PM on Tuesday afternoons in Jorgensen 154. Mark's email address is: mcduff /at/ caltech /dot/ edu. Mark's office hours are from 10-12 PM on Monday evenings in Jorgensen 154.
You are welcome to collaborate informally on your assignments with other individuals who are taking or have taken the class, but you must write all of your own code. Copying another student's code verbatim or nearly verbatim is not acceptable and is an Honor Code violation. Taking another student's file and modifying it to make it look different is definitely not acceptable and is an Honor Code violation. Consulting a printed or electronic version of another student's code and referring to it while you write your own code is not acceptable either, and is an Honor Code violation. Having someone dictate code while you type isn't acceptable either. Basically, you have to do your own work.
Getting advice on algorithms or syntactic details of the language, or suggestions on how to debug a part of your program that isn't working, is fine.
All of the above also applies if you are getting tutored for the course, officially or unofficially.
In addition, of course, if you are having problems you can email me and/or come and see me during my office hours.
Once you have a CS cluster account the normal place to write your code will be in the CS cluster itself, which is in Jorgensen room 154. There is a combination to get into that room which I'll tell you if you ask me (or ask your friends -- it's not that secret). Don't give this combo out to non-Caltech people for obvious reasons.
Most of you prefer to write your code in your dorm rooms, and, sadly, most of you run Windows exclusively on your computers. I'd love to persuade you to change that to a dual-boot Windows/Linux machine like I use (or to use Mac OS X with the developers cdrom installed), but failing that, the easiest way to work remotely is to use the freely-available PuTTy program, which will (among other things) act as a terminal into the CS cluster. Once this is set up, you can log in to the CS cluster login machine to do your work. However, we prefer that you not do this, since a lot of people use that machine for reading their email and doing routine (non time-intensive) tasks. Whatever you do, don't run a computationally-intensive program (like labs 6 or 7) on the login machine, because that will make it slow down to a crawl and you'll receive nasty emails from people (including me).
A different approach is to use Cygwin, which provides a Linux-like environment on Windows machines, including fully-functional versions of the command interpreter (shell) and emacs. Setting up Cygwin is not for the faint-hearted and will chew up a lot of disk space, but if you get it working, it'll be a great environment for this class.
Make a subdirectory of your CS cluster home directory called
~/cs11 (NOTE: ~/CS11 is not
acceptable; we use automated scripts to grab your submissions and they expect
~/cs11). Under that directory, make a new subdirectory called
python (not Python, for the same reason). Put the
files for each week's assignments in a separate subdirectory of this
directory called lab1, lab2, etc. Make sure that
the files in all of your cs11-related directories are world-readable. If you
don't know what this means or how to check if files are world-readable and
change them if they aren't, you need to read
this part of the Unix tutorial and read the man page for the
chmod command. If we can't read your assignments, we can't
grade them and they will be considered overdue. Note that you can check the
permissions on your files by using the "ls" program as "ls
-l"; the permissions are the second thing displayed from the left. To
change the permissions of a file to world-readable, you just need to do:
% chmod o+r filename
for a file called filename. For a directory called
dirname, you have to do
% chmod o+rx dirname
Type man chmod at the prompt to learn more about how and why
this works. However, this shouldn't be necessary; the default permissions
are that all files are world-readable, so unless you changed it yourself you
won't have to do anything.
We'll collect the assignments on the day that they're due. If your assignment is not ready, let us know by email and also let us know when it's ready to be graded. NOTE: If you submit an assignment late, you must send your grader an email when it's ready to be graded. Otherwise, he (or she) will assume that it isn't ready, and your late penalties will continue. This is a really easy way to get a zero on an assignment, so make sure you let us know when your late labs are ready to be graded. If your lab is ready by the due date, you don't need to send us an email.
We'll send you grades and comments by email.
We will ask you to redo assignments under circumstances which may include (but are not restricted to) any of the following:
If this happens, the redone assignment is due one week after we've requested the redo (though we'd prefer if you completed it earlier). we won't grade assignments that we've asked to be redone until they are completed to our satisfaction. If an assignment needs to be redone, you must notify your grader by email when it's ready. If you don't notify him/her, he/she will assume that it isn't ready and grade accordingly. Redone assignments should be placed in the same location as the original assignment, overwriting the old files if necessary.
If a redo is late, the assignment will be graded at 0 and it won't be graded.
Redos will be graded in the same way as initial lab submissions, except that there will be a redo penalty subtracted from the lab. The penalties are as follows:
So for the third redo, the penalty can range from 3 marks (1 + 1 + 1) to 6 marks (1 + 2 + 3). We use a range of penalties because some redos are more extensive than others. The exact penalty will be up to the grader.
We allow a maximum of three redos. If the lab is still not done by then, we will give it a grade based on what has been done, and subtract six (6) marks as a penalty (with a minimum of zero, of course). This will generally mean you'll get a zero, so make sure you work hard to get your redos done correctly.
We will email you back a copy of your code with in-line comments. Our comments will look like this:
### THIS IS ONE OF OUR COMMENTS (ALL UPPER CASE, 3 #'s AT LEFT).
Please don't write your own comments in this style (at least for the duration of this course). For style (code formatting) issues we will sometimes identify the problem via a tag that can be looked up in the python style guide. An example might be:
### STYLE: [STMTS_ON_LINE] i = 1; j = 2; k = 3;
which says to look in the style guide for the style violation called [STMTS_ON_LINE]. If you do that you'll see that we don't like to see more than one statement on a line. Poor code formatting is so common that this notation saves us a lot of work, as well as forces you to read the style guide. In addition, there is also a python style checking program which you will use to check the style of your code. This will give you instant feedback in a way that we can't, but it won't catch all style violations. In CS 11, we are very picky about code formatting, so please use the style checker; it'll save you a lot of time.
When we complain about something in your code, we expect you to fix it. Sometimes we'll say something like "this is OK, but a better way would be...". You should fix that too. Ignoring such comments will lead to an automatic redo. If you don't understand what we're asking you to do, email us or come to our office hours -- don't just ignore the comment and hope it'll go away. This applies even for style violations. We're usually fairly lenient about style checking for the first lab, but not after that.
I (Mike) will often allow the course to be added up to add day; the specific choice will depend on my impression of the student's abilities and on how many students there are in the track. When a student adds the course, all assignments that have been assigned up to that point are due at the due date for the current assignment. Normal late penalties apply with respect to these due dates.
If course enrollment is high (i.e. over 100 students) I won't allow late adds.
We welcome auditors. If we have time, we will grade assignments submitted by auditors. However, this grading has low priority and may not happen (or may not be up to my usual grading standards, or may not be returned promptly).
If course enrollment is high (i.e. over 100 students) we won't grade labs from auditors. You're welcome to come to the lectures and do the labs on your own, but don't expect feedback.