Common Failure Modes in COMP 551
After seeing many hundreds of students pass through COMP 551, we now have an idea of that are some of the most common failures. We want to write them out here so that you can learn from previous student's experience and avoid them. We have broken down the failure modes into four different categories below: maths, coding, logistics, and group assignment.
Logistic failures
- Quiz Deadlines: There are no extensions or late penalties for quizzes, so make sure not to miss the deadline. You have a whole week.
- Assignment groups: You need to choose your groups for EVERY assignment. Your group is not carried over to the next assignment. If you didn't choose a group by the time the assignment starts, you will be randomly assigned to a group. So make sure you register for your group before the deadline if you want to be with someone specific. You can register for your group for all assignments right after add/drop deadline. So do it then if you know you want to be with the same group for the whole term and you don't want to forget later. We don't let you register for groups before add/drop because too many people drop the class before that.
- MyCourses Quiz Design Flaw: If you don't submit a solution to a quiz. After the deadline is passed you won't be able to view the quiz anymore because of MyCourse design flaw which we have no control over. But come exam time you will want to look at it to study. So make sure, when a quiz comes out that you submit a solution, even if it is a blank one (remember you have unlimited submits). That way even if you don't end up doing the quiz, you will be able to look at it later as well as the solutions in order to study.
Group Assignment failures
- My teammate didn't do their part in the assignment: that is not a valid excuse because everyone should do the whole assignment. You can help each other of course, but everyone should complete all of the assignment, otherwise you will not learn all the necessary material. For the submission you can of course take the best of each teammate. But saying that your teammate didn't do their will not be accepted as a valid excuse.
Math failures
- Linear Algebra Index Notation: what is \(y_i = \sum_j M_{ij} x_j + b_i\)? If it is not immediately obvious to you that this means that vector y is equal to vector b plus matrix M multiplying vector x you should really revise index notation for linear algebra. Our slides will be full of such notation and if it is not second nature to you, it will be really difficult to follow along. The good news is that it is not complicated at all, so it should be very easy to review. Here are a few YouTube video explanations of index notation.
- Finding the min/max of a function: let p be a probability value between 0 and 1. For which value of p does \(p \log{p}\) take its maximum value? We all have the reflex to find the zeroes of the second derivative don't we? But sometimes that is not the right thing to do. Where does the second derivative of \(p \log{p}\) equal to zero? What do you do when the second derivative is never zero? When should we be looking at the second derivative and when should we not? Remind yourself of the answers to those questions and you won't fall into those (unintentional) traps. Another example, let p be a probability from 0 to 1 again. For which value of p does \(p(1-p)\) have a minimum? It's not p=0.5. Here is a refresher on YouTube in case you need it:
Coding failures
- Debugging:
You are doing your assignment and you have a bug. It's ok, you can brute-force think of what the bug could be and fix it just by looking at your code. Maybe you can, you're smart after all. You try a few things but nothing works. It's been half an hour now that you try to find the bug but you've found nothing. So you start to write print statements in your code to get an idea of what is happening. NO! STOP! If you continue down this path you will spend 2 days trying to find your bug. You won't find anything, so you will come to my office hour asking me for help. You have lots of code. I don't know your code. 10 more students are waiting in line to ask me questions. "Did you meticulously step through EVERY line of your code in debug mode on your IDE to be sure that each line does what you expect it to?", I will ask you. "No", you will answer. "Do that", I will tell you. So instead of wasting more than 2 days like that. If you've been searching for your bug for more than 30min and still haven't found it, there is only one right thing to so: run your code in debug mode and meticulously step through every line of your code to make sure that every line does exactly what you expect it to do. If it doesn't, you've found your bug. You don't want to do it. I know. It's tedious and boring. I also wouldn't want to do it either if I were in your position. But if you do that, after 30min you will have found and fixed your bug with a probability of almost 1. That is a much better world than the world where you wasted 2 days searching for your bug and never found it.
Some bugs don't happen right away and maybe you can step through all lines of your code and bug didn't appear. A typical example is NaNs appearing after a few epochs of training. If that is what you have. USE CONDITIONAL BREAKPOINTS. Have a conditional breakpoint which is activated when tensor.isnan().any() == True then you can check out what in the formula that created that tensor made it have NaNs.
Now, if you really want to be a God/Goddess of coding, you can do even better. In addition to meticulously stepping through your code in debug mode when something doesn't work like you expect. You can make sure that all your code is bundled in very short functions of 10 lines max, and that each one of those small functions have unit tests including edge cases. For that you can use DocTest.
