Homeworks 8 and 9: Vectors, parts 1 and 2

Table of Contents

1 Pair programming structure

This is a "pair" assignment, which means that if you are working on a team with someone else, you and your partner should do engage in the pair programming model. You should be physically together, sharing a computer and both looking at the same screen. Review the instructions on Moodle about pair programming.

You should make sure that over the course of an assignment that you spend roughly the same amount of time each "driving." My recommendation is to take turns approximately every 10-15 minutes. Set a timer to help you remember. I will also ask you to turn in a form about your partnership when we switch partners and at the end of the term.

If pair programming in real-time just doesn't work for you and your partner, then you will need to amicably split up and work individually. If you choose this option, you must communicate that to me [Anna]. Please do so as soon as that decision is made. If you split, a new partner typically cannot be assigned until the rest of the class switches partners.

1.1 Get started

You'll download the folder with the starter code from the link below. Like for the previous homeworks, unzip the folder and move it to the folder for the Docker container (or COURSES if you're not using Docker). Then get started in VS Code.

If when running tests you run into a permissions error, you can fix this by running the following code in the terminal:

chmod a+x test-e test-m

This tells the computer that all users should be permitted to execute (run) the files test-e and test-m.

Click here to download the starter files

2 Assignment overview

Python, Java, and many other languages have the capability for a list implementation that uses an array that automatically expands itself as necessary. In Python it is simply called a "list"; in Java, it is called an "ArrayList". Generically, it is sometimes referred to as a vector or a dynamic array. C has no such built-in vector capability, though it does have fixed-size arrays. For this assignment, you will implement a vector in C. (Note that while C has so-called variable-length arrays, that only means that you can create an array whose size is given by a variable. It’s still the case that once the array is made, it isn’t automatically resized as needed.)

Your assignment is to add to the file vector.c in the same directory as the starter files. You'll eventually be writing code for all the functions prototyped in vector.h. That means you'll have the same functions as in vector.h (as well as any other functions you wish), with the same input and output types. These functions should have bodies (unlike in vector.h). Make sure to read the comments in vector.h carefully so you know what each function should do, and follow all of the instructions in vector.h. You should change only vector.c; please leave the other files untouched - we will be using our versions of these files for testing, so if you make changes, your code may not pass our tests.

3 Part 1 (complete by first due date)

Implement the functions init, print, insert, get, and cleanup. For insert, you do not need to make the array automatically double for Part 1. You will need to make sure you have minimal stub code in the remaining functions to make it compile.

As usual, you can test your code for correctness with the test scripts ./test-m and ./test-e. If you want to see the tests themselves, the place to look is in tester.c.

Your code should have no memory leaks or memory errors. We'll test this using valgrind, which is a wonderful tool for detecting memory bugs in C. If valgrind produces error messages, this is considered incorrect, so it's important that you check it yourself. The testing scripts automatically run valgrind on your code, so you'll see those errors as well. Additionally, the test scripts will report failures if you have compilation warnings.

When you run the tests, it's fine if you see a message like FAIL: testVectorPart2. What you don't want is FAIL: testVectorPart1. Part 1 is the tests for part 1, and part 2 is the tests for part 2. For part 1, only the part 1 tests need to pass. (Note that Gradescope will run all the tests. Your part 2 tests will fail, and that's okay. Just look at the details on Gradescope to verify which tests are passing.)

4 Part 2 (complete by second due date)

First, let's use the header file a bit more properly now that you've learned more about header files in class. Remove the struct definition and typedef from vector.c, and instead, include the vector.h header file; remember that for includes that aren't part of the standard C library, you'll use quotation marks rather than angle brackets. Test your code using test-m and test-e: the results of the tests should not have changed from before removing the struct definition. If they have, double check what you've done, and make sure you didn't change anything about the struct definition: the version in vector.c should have been identical to the version in vector.h. py Implement any remaining functions that you skipped in Part 1 that were in vector.h, and modify your insert to make the array automatically double in size when needed (as described in the comment for insert).

5 How to test and submit your work

5.1 Testing your work

Go back and look at the sections at the end of Scheme Intro 2 labeled "How to test your work". Everything there about how to run M tests and E tests applies identically here.

5.2 Submitting your work

You'll submit your work on Gradescope. First, create a CollaborationsAndSources.txt file in the same folder as your code. In that file, indicate in what ways (if any) you collaborated with other people on this assignment. Indicate any people you talked about the assignment with besides your partner (if you had one), me (Anna), and our prefect. Did you share strategies with anyone else? Talk about any annoying errors and get advice? These are fine things to do, and you should note them in the CollaborationsAndSources.txt file. Give the names of people you talked with and some description of your interactions. If you used any resources outside of our course materials, that is also something to note in Collaborations.txt. If you didn't talk with anyone or use any outside sources, please note that explicitly in CollaborationsAndSources.txt. Look back at the Scheme Intro 1 instructions if you want more details on the CollaborationsAndSources.txt file.

After making CollaborationsAndSources.txt and finishing the assignment, upload your files on Gradescope. On Gradescope, make sure to add your partner if you worked with a partner. This page has detailed instructions for how to do that.

Note that if you submit a zip on Gradescope, you should submit a zip of the files, not a zip of the folder that contains the files. If all tests fail on Gradescope but they're working on your machine, this is likely the problem.

On Gradescope, you should see autograder output for the same tests as you ran locally. There is a small chance that you have coded something unexpected that cause the tests pass on the computer you’re working on, but not on Gradescope. We will be grading this assignment based on the results of the tests on Gradescope, so you should make sure to pay attention to how the tests run there as well when you submit.

For grading, you'll earn at least an M if the following conditions are all met:

  • All M tests pass
  • A visual inspection of your code shows that you have not hyper-tailored your code to pass the tests. Hyper-tailoring your code would be doing things like checking for the exact input from the test, meaning you haven't written your code in a way that would work for similar inputs.
  • You have a CollaborationsAndSources.txt with the information described above.
  • The assignment is turned in by the late deadline.

You'll earn an E if:

  • All conditions above for an M are met.
  • All the E tests pass.
  • Your code is not significantly more complex than needed to accomplish the task.
  • You have a comment before each function describing what the function does (its input/output behavior, not a play-by-play of "first checks… then makes a recursive call …").
  • The assignment is turned in by the regular deadline, or it is turned in by the late deadline and you choose to use a late token (by submitting a regrade request after the initial grading is complete).

If your code does not meet the criteria for an M or an E, then you'll earn a grade of NA (Not Assessable) or SP (Some Progress) for the assignment. Not Assessable means that your submission does not have an attempt at one or more functions in the assignment. Some Progress means that your submission has some code (in the correct language) for all functions in the assignment, but that the code does not pass all of the M tests, is hyper-tailored to the tests, and/or is missing a CollaborationsAndSources.txt file.

Good luck, ask questions, and have fun!

Assignment modified from one originally designed by Dave Musicant, with improvements from Laura Effinger-Dean and Anna Rafferty - Thanks for sharing!