Class MeetingsSubmitting AssignmentsGrade BreakdownCode ReviewsCollaboration PolicyStudy TipsGitHub CommandmentsLaTeX CommandmentsCoding CommandmentsCoding Integration TroubleshootingPreparing for Eurisko

Class Meetings

Class meetings will take place on Google Hangouts:
Collaboration / help outside of class will take place on Slack:

Computation & Modeling
  • "B" Mondays from 8:30-8:55am
  • Wednesdays/Fridays from 8:30-9:25am

Machine Learning
  • "B" Mondays from 8:45-9:10am
  • Wednesdays/Fridays from 9:10-10:05am

Submitting Assignments

Assignments will be submitted on Canvas. You will just need to paste links to your files, e.g., and shareable links to your Overleaf documents, e.g.

Before you submit your assignment, make sure that your code runs, follows the coding commandments, the LaTeX commandments, and satisfies ALL the requirements outlined in the assignment!

You are welcome (and encouraged) to send me your assignment on Slack to get feedback before you submit. I'm usually able to identify any obvious issues just by taking a quick glance, and it's easiest to fix those issues right away before submitting (as opposed to waiting until "later" to resubmit the assignment after it's already been graded).

Collaboration Policy

In general, you are free to help each other on assignments. However, you are NOT allowed to
  1. share your full solutions with others, or
  2. copy (i.e. plagiarize) others' code. (If you copy code and then change the variable names, it still counts as plagiarism.)

Penalty: Violation of this collaboration policy will result in earning no credit on the assignment, with no opportunity for resubmission.

Here are some examples of things you can vs cannot do:

You CAN:
Post a line of your code, or describe an idea of how to approach a problem, on the #help channelPost your complete code on the #help channel
Screenshare with another student to discuss Python and approaches to problemsShow your full solution that you're going to turn in

Grade Breakdown

Your final grade will be a weighted average of the following categories:
  • Assignments (40%). Every class, you will have an assignment consisting of multiple problems from a variety of domains. Assignments will be graded for both functionality and code quality, and you'll need to submit links to your GitHub commits, the GitHub issue you made, and the GitHub issue your resolved.
  • Biweekly Quizzes (40%). We will have quizzes every other week. The problems will focus on the core principles covered in the assignments.
  • Final (20%). There will be a cumulative final exam.

Late Assignments and Resubmissions: On each assignment, you can resubmit to get back 50% of the points you missed. If an assignment is late, it earns 0 points (but you can resubmit to get up to 50%). So, it's always better to turn in a partially completed homework on time and resubmit the rest, than to turn in everything late. An assignment is late if it is not turned in by the beginning of class on the day that it is due.

Quiz Corrections: Quiz corrections will be assigned as an homework problem. If you don't submit corrections on that assignment, then you will lose points on the homework.

Grades of Zero: You should check the grade and comments on each assignment. If you turned in an assignment but received a grade of 0, that just means there's something you need to fix before I grade it. You can read the comment on your assignment in Canvas to figure out what you need to fix. Usually, you just need to clean up your LaTeX or code so that it follows the commandments. But in order to have your grade updated, you need to fix and resubmit the assignment.

Code Reviews

On each assignment, you will make a GitHub issue on another student's machine-learning, simulation, graph, or space-empires repository (NOT the assignment-problems repository), and you will resolve an issue that another student has made on your own repository. To find the student whose code you are supposed to review, add your student number to the assignment number, modulo the number of students in your class. (Note: once in a while, you will make an issue on your own code.)

Machine Learning
  1. David Gieselman
  2. George Meza
  3. Riley Paddock
  4. Colby Roberts
  5. Elijah Tarr
Computation and Modeling
  1. Nathan Allen
  2. Maia Dimas
  3. Justin Hong
  4. Cayden Lau
  5. Anton Perez
  6. Nathan Reynoso
  7. William Wallius
  8. Charlie Weinberger

Study Tips

To prepare for a quiz, all you really need to do is make sure that you are "fluent" with the relevant problems covered on homeworks. To be clear: simply writing working code is enough to score well on homeworks, but it's not enough to score well on quizzes. For quizzes, you need to make sure that you can quickly work out these problems from scratch, without any help. It's not enough to get to the point of "I think I get this, this makes sense" -- you need to get to the point of "I totally get this, this is easy".

GitHub Commandments

  • Frequent commits: commit your code after completing each assignment. The commit frequency should be once every couple days at most. There should be no periods where you go for more than a couple days without commits (excepting e.g. thanksgiving break, winter break, spring break).
  • Descriptive commit messages: name your commits descriptively. Specify what you did. Don't just name it as the assignment number. For example, some good commit messages would be "fixed rref method in case of rectangular matrix" or "added operator overloading: addition, subtraction, multiplication, division, exponentiation". Some bad commit messages would be "Did Assignment 26" or "Fixed a lot of stuff".

LaTeX Commandments

Assignments requiring written text or math should be done in LaTeX using the Eurisko assignment template.
  • Text inside of equations: use $\textrm{my_variable} = 2$ $\textrm{my_variable} = 2,$ not $my_variable = 2$ $my_variable = 2.$
  • Parentheses around fractions: use $\left( \dfrac{1}{2} \right)$ $\left( \dfrac{1}{2} \right),$ not $( \dfrac{1}{2} )$ $( \dfrac{1}{2} ).$ This applies to brackets, braces, absolute value signs, etc, as well.
  • Exponents and subscripts: use $2^{10}$ $2^{10},$ not $2^10$ $2^10$
  • Vertical bars: whenever you want to use a vertical bar $|$ $|,$ it has to be in a math environment (e.g. between dollar signs, or in an align environment). Otherwise, if you try to use it as plain text, it will turn into a horizontal bar: | ———
  • Align environments: whenever you are manipulating an equation, use an align environment:
        3x+2 &= 5 \\
        3x &= 3 \\
        x &= 1

    $\begin{align*} 3x+2 &= 5 \\ 3x &= 3 \\ x &= 1. \end{align*}$

    Likewise, whenever you are simplifying an expression through multiple steps, use an align environment:
    \int_1^2 x \, \textrm{d}x &= \left. \dfrac{x^2}{2} \right|_1^2 \\
                              &= \dfrac{2^2}{2} - \dfrac{1^2}{2} \\
                              &= \dfrac{4}{2} - \dfrac{1}{2} \\
                              &= \dfrac{3}{2}

    $\begin{align*} \int_1^2 x \, \textrm dx &= \left. \dfrac{x^2}{2} \right|_1^2 \\ &= \dfrac{2^2}{2} - \dfrac{1^2}{2} \\ &= \dfrac{4}{2} - \dfrac{1}{2} \\ &= \dfrac{3}{2} \end{align*}$
  • Integral formatting: use $\displaystyle \int x \, \mathrm{d}x$ $\displaystyle \int_0^1 x \, \mathrm{d}x,$ not $\int x dx$$\int_0^1 x dx$
  • Evaluating at bounds: use $\left. \dfrac{x^2}{2} \right|_{12}^{15}$ $\left. \dfrac{x^2}{2} \right|_{12}^{15},$ not $\frac{x^2}{2} \right|_12^15$ $\frac{x^2}{2} |_12^15.$
  • Arrows under limits: use $\lim\limits_{x \to 0} f(x)$ $\lim\limits_{x \to 0} f(x),$ not $\lim_{x \to 0} f(x)$ $\lim_{x \to 0} f(x).$
  • Expectation and variance: use $\mathrm{E}[X] \mathrm{Var}[X]$ $\mathrm{E}[X] \, \mathrm{Var}[X],$ not $E[X] Var[X]$ $E[X] \, Var[X].$
  • Conditional probability: use $P(\textrm{new event} \, | \, \textrm{old event})$ $P(\textrm{new event} \, | \, \textrm{old event}),$ not $P(new event | old event)$ $P(new event | old event).$
  • Multiplication: use $P(A)P(B), \, P(A) \cdot P(B), \, P(A) \times P(B)$ $P(A)P(B), \, P(A) \cdot P(B), \, P(A) \times P(B),$ not $P(A) * P(B)$ $P(A) * P(B).$
  • Running off the page: if a line of math is running off the page, break it after a term midway and put the rest on the next line like this:
        \int (x + x^2 + x^3 + x^4 + x^5 + x^6) \, \textrm{d}x
             &= \int x \, \textrm{d}x + \int x^2 \, \textrm{d}x + \int x^3 \, \textrm{d}x \\
             &\quad + \int x^4 \, \textrm{d}x + \int x^5 \, \textrm{d}x + \int x^6 \, \textrm{d}x \\
             &\quad + \int x^7 \, \textrm{d}x + \int x^8 \, \textrm{d}x + \int x^9 \, \textrm{d}x

    $\begin{align*} \int (x + x^2 + x^3 + x^4 + x^5 + x^6) \, \textrm{d}x &= \int x \, \textrm{d}x + \int x^2 \, \textrm{d}x + \int x^3 \, \textrm{d}x \\ &\quad + \int x^4 \, \textrm{d}x + \int x^5 \, \textrm{d}x + \int x^6 \, \textrm{d}x \\ &\quad + \int x^7 \, \textrm{d}x + \int x^8 \, \textrm{d}x + \int x^9 \, \textrm{d}x, \end{align*}$
    Don't keep it all on one line. So, don't do this:
        \int (x + x^2 + x^3 + x^4 + x^5 + x^6) \, \textrm{d}x = \int x \, \textrm{d}x + \int x^2 \, \textrm{d}x + \int x^3 \, \textrm{d}x + \int x^4 \, \textrm{d}x + \int x^5 \, \textrm{d}x + \int x^6 \, \textrm{d}x + \int x^7 \, \textrm{d}x + \int x^8 \, \textrm{d}x + \int x^9 \, \textrm{d}x

    $\begin{align*} \int (x + x^2 + x^3 + x^4 + x^5 + x^6) \, \textrm{d}x = \int x \, \textrm{d}x + \int x^2 \, \textrm{d}x + \int x^3 \, \textrm{d}x + \int x^4 \, \textrm{d}x + \int x^5 \, \textrm{d}x + \int x^6 \, \textrm{d}x + \int x^7 \, \textrm{d}x + \int x^8 \, \textrm{d}x + \int x^9 \, \textrm{d}x. \end{align*}$

Coding Commandments

You SHALL...
abide by Python conventions
  • variables, functions, and files use snake_case
  • classes use PascalCase
  • indents are 4 spaces
name things what they are
  • variables and classes should be nouns
  • functions (including methods) should be verbs
  • names should be descriptive. It's okay to make a name several words long if you need. For example, compute_conditional_probability() is WAY better than cp() or prob().
lint your code

You shall NOT...
set a class attribute outside of the class itself
Don't do this:

  A = Matrix(elements = [[1,2], [3,4]])
  B = A.copy()
  B.num_rows += 1
Do this instead:

  A = Matrix(elements = [[1,2], [3,4]])
  b_elements = A.elements
  B = Matrix(elements = b_elements)

tailor general classes to specific problems
Don't do this:

  poly_regress = PolynomialRegressor()
  poly_regress.solve_coefficients(sandwich_situation = True)
Do this instead:

  Do the analysis manually, without the class PolynomialRegressor.
  You can still use code from the class, but you should not actually modify the class.

use inheritance in the absence of an "is-a" relationship
Don't do this:

  class Board(Player):

  (the Board is NOT a Player)
Do this instead:

  class Board:

give two methods similar and non-descriptive names
Don't do this:

  def move():

  def movement():
Do this instead:

  def move():

  def get_previous_movement():

have a single function with two purposes
Don't do this:

Do this instead:

  Use two different functions:


use a long list comprehension
Don't do this:

  flips = ' '.join([''.join([['T','H'][round(random.random())] for _ in range(num_flips_per_sample)]) for _ in range(num_samples)]
Do this instead:

  Break it up.

  flips = ''
  for _ in range(num_samples):
       sample = ''
       for _ in range(num_flips_per_sample):
            random_flip_is_heads = round(random.random())
            random_flip = ['H', 'T'][random_flip_is_heads]
            sample += random_flip
       flips += ' ' + sample"

reference object attributes indirectly
Don't do this:

  "combat_stats = {
       'attack': unit1_attack,
       'defense': unit1_defense,
       'opponent_attack': unit2_attack,
       'opponent_defense': unit2_defense
  if combat_stats['attack'] > combat_stats['opponent_defense']:
Do this instead:

  Use the object directly.

  if unit1.attack_strength > unit2_defense_strength:

use arrays to store nonhomogenous data
Don't do this:

  sample_stats = ['HHT', 2/3, 1/3]
Do this instead:

  Use a dictionary:

  sample_stats = {
       'flips': 'HHT',
       'proportion_heads': 2/3,
       'proportion_tails': 1/3


Before you ask for help on a problem, you need to make a thorough effort to debug the issue on your own. Here is how you debug:
  1. Print out everything. Within the function that you're debugging, print out every manipulation that your code makes, even if you don't think it's making a mistake there. (Bugs often show up in places you don't expect.) Also, don't just print out the values of variables -- rather, you should label your printouts with text descriptions of what they represent.
  2. Identify the first discrepancy. Manually work out what the printouts should be, and then look for the first instance when the actual printouts deviate from what you're expecting.
  3. If the discrepancy involves a helper function, then isolate the issue in a separate file and return to step 1. If the issue is occuring when you're passing inputs into a helper function, then create a separate file where all you do is pass those inputs into the helper function. Now, you need to debug the helper function, which means you go back to step 1 (print out everything) with this helper function.
  4. If the discrepancy does not involve a helper function and you still can't figure out what's going wrong, then post on #help. In your post, explain what you've done to debug the issue so far, including the furthest point back to which you've traced the bug. Keep your debugging print statements in your function. Integration Troubleshooting

My repl was originally successfully pushing code up to Github, but now it keeps failing to do so. What should I do?
First, try refreshing the page and pushing again. If it still fails, then keep reading.

It's been known to happen that a repl might randomly stop being able to push to Github. It's not clear why this happens, but the solution is just to move your code over to a new repl, and then replace the old repl with the new repl. Here's an efficient way to do that, without having to copy and paste all of your files:
  1. Create a new repl with the same name as the old repl
  2. Connect the new repl to the existing github repository
  3. Pull the github repository to your new repl
  4. Copy any recent changes from your old repl to your new repl (i.e. just those changes that didn't get pushed up to github)
  5. In your new repl, push the changes back up to your existing github repository
  6. Your new repl is now fully up-to-date and connected to your github, so you can delete the old repl
My repl won't push code up to Github, and I've made changes to my code in a ton of different files since I last pushed up to Github. How can I start working from a new repl without losing all my changes?
First of all, you should be pushing to Github often enough that this doesn't happen. But now that you're in this situation, let's get you out of it.
  1. Zip all your current code into a single zip file. You can do this by clicking on the three dots in the main heading of the "Files" panel and selecting "Download as zip".
  2. Manually upload your zip file to Github. You can do this by going to your Github repository, clicking "Upload a file", dragging your zip file, and committing.
  3. Create a new repl with the same name as the old repl.
  4. Connect the new repl to the existing github repository.
  5. Pull the github repository to your new repl.
  6. In your new repl, unzip your zip file by typing unzip -o into the command line. (You should replace "filename" with the actual file name of your zip file.)
  7. Delete your zip file by typing rm into the command line.
  8. In your new repl, push your code back up to your existing github repository.
  9. Your new repl is now fully up-to-date and connected to your github, so you can delete the old repl.