Project 4, CSC 202
1 Hashing
2 Design Recipe
3 A note about automated testing
4 Import restrictions
5 Handin instructions
6 Automated Testing
6.1 Checking that you Submitted
8.13

Project 4, CSC 202🔗

1 Hashing🔗

For this project, you will implement a Concordance for text, using a hash table.

Here’s the invitation link for this project.

Here’s a link to the project description.

2 Design Recipe🔗

For each function required in this assignment, you should follow the design recipe, as described in this document. Specifically, each function should come with a purpose statement, types for both parameters and return type, and a full set of tests (unless the specification states that no tests are required for a particular function).

3 A note about automated testing🔗

You should use an @dataclass(frozen=True) decorator to define all classes created in this assignment, except where specifically instructed.

4 Import restrictions🔗

In order to make it possible to test and analyze your code, it’s important that we be able to run it in a consistent environment.

Specifically, we will run your code with Python 3.12.3, in an environment that includes only the standard packages along with mypy. Please don’t import packages other than dataclass, typing, unittest, and math, and of course other parts of your own source code. If I’ve left something important off this list, let me know!

5 Handin instructions🔗

Submit this assignment by pushing to the repository created for you by GitHub classroom.

6 Automated Testing🔗

We will be using some automated testing in order to check the correctness of your code. For this reason, it’s important that names be spelled as specified, and that fields and parameters occur in the order specified in the text.

Please note that the repository also contains a file called "basic-tests.py", and these tests are run automatically when you push to GitHub. These tests don’t verify that your code is correct, they simply verify that you have defined the right functions, and that they have the right number of arguments, and that they return the right kind of thing. These tests exist because it’s very sad when you are supposed to develop a function named (say) "success" and you accidentally name it (say) "succcess" and then all of the tests fail.

You can run these tests yourself, using

python3 basic-tests.py

... or by running this file in your favorite IDE.

These tests are also run for you when you push to GitHub, and you should see either a green check next to your submission if the tests passed, or a red X if they didn’t pass.

In general, files that don’t pass the basic tests may receive a score of zero on the assignment.

Please note that editing the "basic-tests.py" file is a terrible idea; the whole point of "basic-tests.py" is to ensure that the post-submission tests run correctly; editing this file is like using chewing gum to stick the needle of your thermometer to 80 degrees — it won’t actually make our tests pass, it will just obscure the real signal.

6.1 Checking that you Submitted🔗

If you’re not familiar with the overly complex nature of git, it’s very very possible to do all the work and commit it locally but fail to push it to GitHub classroom, in which case it will appear to us that you’ve done no work at all, which is very sad.

In order to check that your work is checked in, use the GitHub web interface to ensure that the version of the code that appears on GitHub is the most updated version, and that it passes all of the basic tests.