Assignments🔗

Logistics

Please make sure all submissions are anonymous.

We will use Gradescope for assignment submission and grading. We will post instructions on EdStem. Please make sure you follow those instructions!

All work will be due by 11:59pm US/Eastern of the indicated day.

Assignment Schedule

Name		Group?		Late?		TA?		Published		Due
DocDiff		no		no		yes		Wed, Sep 3		Sat, Sep 6
Tables		no		yes		no		Sun, Sep 7		Wed, Sep 10
Sortacle		no		no		yes		Thu, Sep 11		Mon, Sep 15
Assign		no		no		yes		Tue, Sep 16		Sat, Sep 20
Oracle		yes		no		yes		Sun, Sep 21		Thu, Sep 25
Tables PR		no		no		yes		Fri, Sep 26		Sun, Sep 28
Updater		yes		no		yes		Mon, Sep 29		Sat, Oct 4
JoinLists		no		yes		yes		Sun, Oct 5		Fri, Oct 10
Contfracs		no		yes		yes		Tue, Oct 14		Fri, Oct 17
Reactive		opt.		no		yes		Sat, Oct 18		Tue, Oct 21
Join Lists PR		no		no		yes		Wed, Oct 22		Thu, Oct 23
MST		no		yes		yes		Fri, Oct 24		Thu, Oct 30
Conversions		no		yes		no		Fri, Oct 31		Thu, Nov 6
MST PR		no		no		yes		Fri, Nov 7		Sat, Nov 8
Map Reduce		yes		no		no		Sun, Nov 9		Thu, Nov 13
Fluid Images		no		yes		yes		Fri, Nov 14		Sun, Nov 23
24.1		no		no		no		Mon, Dec 1		Wed, Dec 3
24.2		no		no		no		Thu, Dec 4		Fri, Dec 5

All SRC tasks will be due two days after the corresponding assignment.

The Group? column says whether you have to do that assignment solo or in a group. A group is two to three people. We will post instructions on group formation on EdStem. If it says that groups are optional, then you can form a group of one or two other people on your own, or work solo, whichever you prefer. You cannot repeat partners across group assignments. Please read and follow these rules and guidelines for all group assignments.

The Late? column says whether you are allowed to use late days for this assignment. Please see the Syllabus and Course Policies for information about late days.

The TA? column indicates whether you can get help from course staff (whether in person or on EdStem) for this assignment. For many assignments you can. But for a handful (usually simpler) assignments, we want you to work through them on your own and make sure you can do the work in this class by yourself—think of it as exam mode. (If it’s a group assignment, then you can of course work together as a group.) EdStem posts will be limited to clarifications of errors on the assignment: you can’t ask for help, but you can check if you think, for instance, there’s a mistake.

Style Grading Standards

We apply the following grading standards to your programming work.

• Docstrings.

  You no longer need to write docstrings for every single function. Instead, the rule is:

  • If you are implementing a function specified in the assignment statement, then clearly the assignment already documents your function. Your docstring should simply be the assignment’s URL. (This confirms for us that you’re trying to follow the assignment precisely.)

  • If the function is clear enough without having to read the body, it doesn’t need a docstring. That is: if a reasonable person, given the function name, header, and an example or two, can figure out what it’s doing, it doesn’t need a docstring. Of course, there’s a big judgment call here! There are two ways to avoid confusion:

    1. Break the function down into components that are sufficiently focused and clearly named, or

    2. write a docstring!

    Note that peer-review is a good time to tell someone, “you really should have written a docstring!”. If they didn’t write one and the function failed the above test, let them know. Through this process of getting feedback from course staff and peers, and of giving feedback yourself, you will be able to develop an intuition for when you can truly safely skip writing a docstring.

  • For all other functions, write a docstring! This is especially true for any non-trivial helper functions that you write.

• Testing.

  We distinguish between “interface” functions — those required by the problem statement — and everything else, which we’ll call “helper” functions.

  We expect to see extensive testing for interface functions, as before. This is the product you’re delivering to the customer, so you have an obligation to make sure it’s very robust.

  For each helper function, it’s okay to have a small number of tests. You don’t have to test every edge case that the function could possibly have, but you should still test every edge case that your code depends on. Remember: tests are your best "debugging" strategy! But we will not penalize you if you have only 2–3 reasonable tests for each helper function.

Lab Schedule

Week of		Topic
Sep 15		Big-O
Sep 22		Tree Iterators
Sep 29		Shell
Oct 6		Queues and Priority Queues
Oct 20		Heaps
Oct 27		Flexible Arrays
Nov 3		SQL
Nov 10		Git
Nov 17		Help with ssh, etc. (optional!)

Written Material Turnin

Please turn in all written material (big-O analysis, SRC, etc.) in one of only two forms: text file or PDF. Those are the only formats that Gradescaope can preview, so graders can see and review them in-place instead of having to download them (which clutters up their filesystem), open them in a separate app (which they may not have), etc. In particular, if you use Word, please export the file to PDF for upload.

Pyret Rules

The course homeworks will be programmed in Pyret,Please program according to the Pyret Style Guide. unless indicated otherwise. Pyret is a reasonably large language with many libraries, some of which reproduce functionality (like basic data structures) that we are asking you to create in this course. This can lead to some confusion about what you are and aren’t allowed to use from the language. Each assignment provides information about this when necessary, but in general, the following rules apply:

• You can always use the computational core of the language: basic constants, functions, higher-order functions, and composition.

• You can always construct your own new data definitions, unless explicitly stated otherwise.

• You are allowed to use builtin functions for the following datatypes unless explicitly stated otherwise:

  • Numbers (functions such as num-abs, num-max)

  • Strings (functions such as string-to-number, string-length)

  • Booleans (functions such as not)

• You are allowed to use the following libraries unless explicitly stated otherwise:

  • lists

  • sets

  • pick

  • tables

  • option

  • either

• You should not use any other built-in functions or libraries unless an assignment explicitly permits you to. When in doubt, ask.

• You may not use variables (var) or mutate them (:=), or have mutable objects (ref) or mutate them (!), unless explicitly permitted to by an assignment.

Finally, when you have a -common.arr file, please do not define any required functions inside it. To test your tests, we run our implementation of the required functions against your -tests.arr file. We also include the bindings and definitions inside the -common.arr file, since you might have graph definitions or testing-related functions inside the common file. At the same time, we also include our implementation of the required functions. So, now the file has conflicting definitions for the required functions, and the autograder fails.