CSCI 0190 · Fall 2026

Assignments🔗

Logistics

Please make sure all submissions are anonymous.

We will use Gradescope for assignment submission and grading.

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

Assignment Schedule

✓ = yes, ✗ = no, O = optional, blank = the column’s default (shown under its header).

Name	Group? ✗	Late? ✓	TA? ✓	AI? ✗	Published	Due
Tables		✗			Wed, Sep 9	Sat, Sep 12
Sortacle		✗			Sun, Sep 13	Wed, Sep 16
Sorting Robustness		✗			Thu, Sep 17	Sun, Sep 20
Proof of Sort					Mon, Sep 21	Tue, Sep 22
LabAssign			✗	O	Wed, Sep 23	Fri, Sep 25
BosBike 1	✓	✗			Sat, Sep 26	Mon, Sep 28
Reactive	O	✗			Wed, Sep 30	Sun, Oct 4
BosBike 2		✗	✗	O	Mon, Oct 5	Wed, Oct 7
BosBike 3			✗	O	Thu, Oct 8	Fri, Oct 9
ContFracs					Wed, Oct 14	Sat, Oct 17
Requirements 1	✓	✗	✗	O	Wed, Oct 21	Sun, Oct 25
MST					Mon, Oct 26	Sun, Nov 1
Finding Paul					Mon, Nov 2	Wed, Nov 4
Finding BYO					Fri, Nov 6	Mon, Nov 9
Requirements 2			✗	O	Tue, Nov 10	Fri, Nov 13
Proof Comparison					Sat, Nov 14	Sun, Nov 15
More Proof Analysis					Mon, Nov 16	Wed, Nov 18
Fluid Images					Thu, Nov 19	Tue, Nov 24
Tour Planner		✗	✗	✓	Mon, Nov 30	Sun, Dec 6

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 some 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.

The AI? column indicates whether you are or are not permitted to use AI to do the work. Additional details will be given in the assignment itself.

Lab Schedule

Week of	Topic
Sep 14	Induction
Oct 5	SQL
Oct 19	Shell
Oct 26	Git
Nov 9	Help with Docker, ssh, etc.
Nov 16	Flexible Arrays

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.

Written Material Turnin

Please turn in all written material 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, if you are in a setting where you are given a file whose name ends in -common.arr, 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.