FAQ


  1. Can I take courses that overlap with CS229?
  2. Yes. If you require an instructor’s signature, please reach out to Prof. Tengyu Ma.
  3. Difference between 3 and 4 units
  4. The class can be taken with 3 or 4 units for undergraduates and graduate students.There is no difference in workload between them. We'd set it up this way mainly to give people more flexibility, and you're welcome to pick either. We generally encourage students to register for 4, but if you'd rather do 3 for any reason (such as if you have a cap on their number of units), registering for 3 is fine too (you do not need to ask for approval).
  5. Is this the same class as the free machine learning class?
  6. No, that is a different class, which is not good for Stanford academic credit. You can learn more about it at www.ml-class.org.
  7. When will solutions for problem sets be released?
  8. Solutions will be released after problem sets have been graded and around the same time as grades are published. For HW0, solutions will be released soon after the submission deadline.
  9. Why am I seeing out-dated webpage with information from previous quarters?
  10. We try our best to keep the website up-to-date starting from a few days before the quarter starts. You might want to force reload the page and override local cache:
      On Mac, use Command + Shift + R.
      On Windows/Linux, use Ctrl + Shift + R.
  11. How I should ask for TAs to help me debug the code:
  12. Please note that the teaching staff will not debug code longer than 2-3 lines via Piazza. Learning to debug is a critical skill for software programmers, and remote requests for help with code usually end up with the teaching staff giving you the answer rather than you learning how to find the answer.
    Moreover, since programming at the level of CS106A/B is a prerequisite for this course and the course’s focus is on machine learning techniques rather than coding, the TAs are discouraged from helping you look at and debug large blocks of your code during the office hours. The TAs are also generally discouraged to help debug compilation errors.
    The best way to use office hours and ask TAs for coding questions would be:
    • You should come to office hours having done your own legwork and ruled out basic logical errors. Identify the place where the error is suspected to come from by doing ablation studies. (Please see below for some common debugging tips.)
    • During the office hours, you should articulate what your goals are and what you have observed with experiments, what you have tried/observed, what you think might be the problem, and what advice you need to move forward.
    • The TAs will mostly help you by looking at and analyzing the outputs of your code instead of looking at the original code. Typical advice that the TAs might advise you would be to ask you to do more analytical or ablation studies about your code. For example, when you observe that your test error doesn’t decrease as training for longer, the TAs might ask you to check if your training error decreases. If your training error does not decrease, then the TAs might ask to check if the gradient of your algorithm is implemented correctly.
    Here are some common debugging strategies that might be useful (courtesy of CS221)
    • Construct small test cases that you have worked through by hand and see if your code matches the manual solution.
    • Spend some time understanding exactly what the test cases are doing and what outputs they are expecting from your code.
    • If possible, write your codes in small chunks and test that each part is doing exactly what you expect.
    • PDB is the default python debugger. It is very helpful and allows you to set breakpoints. You can set a breakpoint with the following line: import pdb; pdb.set_trace()
    • Printing the state of your computation frequently can help you make sure that things are working as expected and can help you narrow down which portion of your code is causing the bug you are seeing, e.g. print(“var1 has current value: {}“.format(var))
    Debugging tips for timeouts:
    • Set operations in general are pretty slow, so if you have any see if you can do them in some other way.
    • Check if all loops / linear operations are necessary. For example, with searching through a list for a specific item, sometimes you can make that constant time by giving each of them an ID (say 0, 1, 2, 3) and then using a dictionary as a cache (although sometimes you just have to live with the cost).
    • If you have a specific helper function you’re calling a lot, see if there’s anything in there you can optimize!”.
    Other debugging tips:
    • If you don’t know what type a variable is, use type(.)
    • If you are running into issues where “None” pops up, a function may not be returning what you are expecting.
    • For indexing into lists: example_list[a: b] is INCLUSIVE for a but EXCLUSIVE for b
    • If a function has optional arguments, make sure you are feeding in the proper arguments in the proper places (very easy to mess up)
    • Since python 3.6, you can use f-strings for printing debug messages, rather than format.
    • Because of broadcasting and other implicit operations, it's useful to assert shapes of np arrays (and tensors for deep learning) after each operation that can change the shape.