CS221: Artificial Intelligence: Principles and Techniques

Communication: We will use Piazza for all communications: announcements and questions related to lectures, assignments, and projects. NOTE: If you enrolled in this class on Axess, you should be added to the Piazza group automatically, within a few hours. You can also register independently; there is no access code required to join the group. SCPD students, please email scpd-gradstudents@stanford.edu or call 650-204-3984 if you need assistance.
Gradescope: You will submit all assignments and project milestones on Gradescope, where you will also find your grades.
Course assistants:

Reid Pryzant (Head CA)

Di Bai

Horace Chu

Will Deaderick

Haoshen Hong

Cindy Jiang

Dhruv Kedia

Jon Kotker

Marcus Pålsson

Chuanbo Pan

Jerry Qu

Sharman Tan

Christopher Waites
What is this course about? What do web search, speech recognition, face recognition, machine translation, autonomous driving, and automatic scheduling have in common? These are all complex real-world problems, and the goal of artificial intelligence (AI) is to tackle these with rigorous mathematical tools. In this course, you will learn the foundational principles that drive these applications and practice implementing some of these systems. Specific topics include machine learning, search, game playing, Markov decision processes, constraint satisfaction, graphical models, and logic. The main goal of the course is to equip you with the tools to tackle new AI problems you might encounter in life.
Prerequisites: This course is fast-paced and covers a lot of ground, so it is important that you have a solid foundation on both the theoretical and empirical fronts. You should have taken the following classes (or their equivalents):
Reading: There is no required textbook for this class, and you should be able to learn everything from the lecture notes and homeworks. However, if you would like to pursue more advanced topics or get another perspective on the same material, here are some books: Bear in mind that some of these books can be quite dense and use different notation terminology, so it might take some effort to connect up with the material from class.
Video Access Disclaimer: Video cameras located in the back of the room will capture the instructor presentations in this course. For your convenience, you can access these recordings by logging into the course Canvas site. These recordings might be reused in other Stanford courses, viewed by other Stanford students, faculty, or staff, or used for other education and research purposes. Note that while the cameras are positioned with the intention of recording only the instructor, occasionally a part of your image or voice might be incidentally captured. If you have questions, please contact a member of the teaching team.
Office Hour Logistics



Written assignments: Homeworks should be written up clearly and succinctly; you may lose points if your answers are unclear or unnecessarily complicated. Here is an example of what we are looking for. You are encouraged to use LaTeX to writeup your homeworks (here's a template), but this is not a requirement. You will receive one (1) bonus point for submitting a typed written assignment (e.g. LaTeX, Microsoft Word). We will accept scanned handwritten assignments but they will not receive the bonus point.
Programming assignments: The grader runs on Python 3, which is not guaranteed to work with older versions (Python 2.7). Please use Python 3 to develop your code.

The programming assignments are designed to be run in GNU/Linux environments. Most or all of the grading code may incidentally work on other systems such as MacOS or Windows, and students may optionally choose to do most of their development in one of these alternative environments. However, no technical support will be provided for issues that only arise on an alternative environment. Moreover, no matter what environment is used during development, students must confirm that their code (specifically, the student's submission.py) runs on Gradescope,.

The submitted code will not be graded if it has one of the following issues:

  • The original grader.py script (operating on the submitted submission.py) may not exit normally if you use calls such as quit(), exit(), sys.exit(), and os._exit(). Also note that Python packages outside the standard library are not guaranteed to work. This includes packages like numpy, scikit-learn, and pandas.
  • The code reads external resources other than the files given in the assignment.
  • The code is malicious. This is considered a violation of the honor code. The score of the assignment will be zero (0) and the incident will be reported to the Office of Judicial Affairs.
Collaboration policy and honor code: You are free to form study groups and discuss homeworks and projects. However, you must write up homeworks and code from scratch independently, and you must acknowledge in your submission all the students you discussed with. The following are considered to be honor code violations:
  • Looking at the writeup or code of another student.
  • Showing your writeup or code to another student.
  • Discussing homework problems in such detail that your solution (writeup or code) is almost identical to another student's answer.
  • Uploading your writeup or code to a public repository (e.g. github, bitbucket, pastebin) so that it can be accessed by other students.
  • Looking at solutions from previous years' homeworks - either official or written up by another student.
When debugging code together, you are only allowed to look at the input-output behavior of each other's programs (so you should write good test cases!). It is important to remember that even if you didn't copy but just gave another student your solution, you are still violating the honor code, so please be careful. We periodically run similarity-detection software over all submitted student programs, including programs from past quarters and any solutions found online on public websites. Anyone violating the honor code will be referred to the Office of Judicial Affairs. If you feel like you made a mistake (it can happen, especially under time pressure!), please reach out to the instructor or the head CA; the consequences will be much less severe than if we approach you.


Electronic Submission: All assignments are due at 11pm (23:00, not 23:59) Pacific time on the due date. Assignments are submitted through Gradescope. Do not submit your assignment via email. If anything goes wrong, please ask a question on Piazza or contact a course assistant. If you need to sign up for a Gradescope account, please use your @stanford.edu email address. You can submit as many times as you'd like until the deadline: we will only grade the last submission. Submit early to make sure your submission runs properly on the Gradescope servers. Gradescope will run grader.py on the programming questions and give you feedback on non-hidden test cases. You are responsible for checking that your program runs properly on these cases. You will not get credit otherwise. If anything goes wrong, please ask a question on Piazza or contact a course assistant. Do not email us your submission. Partial work is better than not submitting any work.

For assignments with a programming component, we will automatically sanity check your code in some basic test cases, but we will grade your code on additional test cases. Important: just because you pass the basic test cases, you are by no means guaranteed to get full credit on the other, hidden test cases, so you should test the program more thoroughly yourself!

Unless the assignment instructs otherwise, all of your code modifications should be in submission.py and all of your written answers in <assignment ID>.pdf. Upload the former to Gradescope under the "Programming" section, and the latter under the "Written" section.
For the project milestones, make sure the all members of your group submits. The submission should include a group.txt file which should contain the SUNetIDs of the entire group, one per line.

Late days: An assignment is $\lceil d \rceil$ days late if it is turned in $d$ days past the due date (note that this means if you are $1$ second late, $d = 1$ and it is 1 day late). You have seven (7) late days in total that can be distributed among the assignments (except for p-poster, p-peer, and p-final) without penalty. After that, the maximum possible grade is decreased by 25% each day (so the best you can do with $d = 1$ is 75%). As an example, if you are out of late days and submit one day late, a 90 will be capped at a 75, but a 72 will not be changed. Note that we will only allow a max of $d = 2$ late days per assignment, though, so if $d > 2$ then we will not accept your submission. Gradescope is set up to accept written and programming submissions separately. Late days are calculated per-assignment, with the number of late days used depending on the later submission. So, if the programming part is $1$ day late and the written part is $2$ days late, then that will count as using $2$ late days.
Regrades: If you believe that the course staff made an objective error in grading, then you may submit a regrade request for the written part of your assignment. Remember that even if the grading seems harsh to you, the same rubric was used for everyone for fairness, so this is not sufficient justification for a regrade. It is also helpful to cross-check your answer against the released solutions. If you still choose to submit a regrade request, click the corresponding question on Gradescope, then click the "Request Regrade" button at the bottom. Any requests submitted over email or in person will be ignored. Regrade requests for a particular assignment are due by Sunday 11:59pm, one week after the grades are returned. Note that we may regrade your entire submission, so that depending on your submission you may actually lose more points than you gain.