Mps on CPSC221 2018W2: Data Structures

PA3

Tue, 12 Mar 2019 12:00:00 +0000

UPDATES!

NOTE: Clarifications, updates, and hints to solving this PA can be found on this piazza page: https://piazza.com/class/jpu51kyvbx9ps?cid=1779

Lab machines

We will be grading the PAs for this course using an image similar to the remote Linux machines. Any errors that you run into as a result of developing your code on other machines are your own responsibility.

Goals and Overview

In this PA (Programming Assignment) you will:

learn about algorithmic art.
learn about an unusual algorithm for lossy image compression.
learn about space partitioning trees called Quad Trees.
learn about clever mechanisms for speeding up statistical algorithms.
learn to be aware of memory usage in recursive programs.

The Assignment, Part 1: Inspiration and Background

The inspiration for this assignment came from an article about an artist whose work recreates classic portraits with a blocky effect. The exact algorithm he used is not given in the article, but we will create similar images using a strategy for image representation that underlies common lossy image compression algorithms.

The two images below illustrate the result of this assignment. Note that the image on the right sacrifices color detail in rectangles that do not contain much color variability in the original image, but maintains detail by using smaller rectangles in areas of the original image containing lots of variability.

In specifying the algorithm we make several conventional assumptions, illustrated below:

The origin, position (0,0), is in the upper left corner of the image.
Rectangles are typically specified either by a pair of points at its upper left and lower right corners, or by an upper left point, together with dimensions (this assingment uses both).
The upper left corner of a rectangle is the one nearest to the origin.
Image locations are typically specified as (x,y), where x is a horizontal offset, and y is a vertical offset.

QuadTrees on a Torus

The original image will be represented in memory as a 4-ary tree whose nodes contain information about square subsets of the image.

Every node is the root of a subtree that represents a subset of the original image. Note that the region might not be contiguous in the original image.
Every node also contains a pixel that represents the average color over the square in the original image.
Every node contains a dimension that determines the size of the square it represents. If dimension == d, then the node represents a $$2^d\times 2^d$$ square.
When a square is split into four smaller squares, the parent node represents the whole square, and the 4 children each contain a quadrant of the original.
Each square is split into 4 equal sized quadrants by an optimal choice of “splitting” point, described below.
Before pruning, every leaf in the tree corresponds to a pixel in the original image, and every pixel is represented by some leaf. The image below represents a part of the unpruned quadtree. We did not draw the leaves in the diagram.

Consider every node to represent a square image that you will subdivide into 4 children nodes. In order to determine how to partition the square, you will find a splitting point from among the points in the light green region in the image below (in general, this will be a $$2^{k-1} \times 2^{k-1}$$ square in the middle of the $$2^k\times 2^k$$ image:

Traverse the pixels in the green square, looking for the one which minimizes the average entropy (described below) over the 4 squares it determines. In this example, we suppose the pixel containing the orange dot gives the minimum entropy score. That orange dot pixel will become the upper left corner of the SE quadrant of the 4-way split.

The center found in the illustration will be the upper left corner of the square that we will call SE, for Southeast because it is below and to the right of the optimal splitting point. The squares marked NW, SW, and NE are the upper left corners of the 3 other squares determined by the split. You will need to compute these locations, given the optimal splitting point, and considering that the edges of the square image wrap around to meet.

Once you have an optimal splitting point, and the upper left corner of all 4 squares, you will explicitly create the 4 squares as the bases for the current node’s children. The illustration shows you how to build the NW child.

Note that in the general case, one of the 4 squares will be a whole square subset of the current image, one will be a horizontal shift into segments where part of the square is on the right of the image, and part is on the left, corresponding to SW in the example above (note that the number of shifted locations might be 0), one will be a similar vertical shift (again, where the shift might be 0), and one will be both a horizontal and a vertical shift (again, where one or both directions’ shifts might be 0).

Finally, the squares you reconstruct out of a partition of the current square are (recursively) the basis for the child nodes.

Entropy

Splits are performed so as to minimize hue variability across the resulting squares. The variability measurement we use is the entropy, which is computed as a function of the distribution of colors in a rectangle as follows: Given a relative frequency table of the colors over some rectangle, where $p_i$ represents the fraction of pixels whose hue, $h$, is $10\cdot i\leq h < 10\cdot(i+1)$, the entropy for the rectangle is

$$ -\Sigma_{i=0}^{35} ~p_i\log_2(p_i). $$

The entropy of a split is the average of the entropy of the 4 resulting squares. (In the case of ties, we choose the split which occurs first in a column-wise navigation of the feasible region of splits.)

As part of this assignment, we build a data structure that allows us to find the histogram of colors for any rectangle, in constant time. To that end we build a 2D vector structure whose cells, (i,j), each contain a frequency table for the rectangle with upper left corner (0,0), and lower right corner (i,j).

The first two splits of the image of Vancouver City Hall are illustrated in the second image below.

To achieve an artistic effect we prune, or cut off, parts of the quadtree. A parameter, tolerance, is used to evaluate a subtree’s suitability for pruning. A node is pruned if all of the leaves in its subtree are within tolerance of its average. To prune a node, simply clear the memory associated with each of its four children, leaving the node a leaf. Distances between colors are computed using the HSLAPixel dist function.

The Assignment, Part 2: Coding

Problem Specification

Specifications for each function you write are contained in the given code. The list of functions here should serve as a checklist for completing the exercise.

In `class stats`:

stats(PNG & im)
HSLAPixel getAvg(pair<int,int> ul, pair<int,int> lr)
long rectArea(pair<int,int> ul, pair<int,int> lr)
double entropy(pair<int,int> ul, pair<int,int> lr)
double entropy(vector<int> distn, int area)

In `class toqutree`:

void clear(Node * & croot)
Node * copy(const Node * croot)
toqutree(PNG & imIn, int dim)
PNG render()
void prune(int tol)
int size()
Node * buildTree(PNG * im, int k)

Implementation Constraints and Advice

We will be grading your work on functionality, efficiency, and memory use.

The stats class is used only for constructing a node of the toqutree. The choice of optimal split requires the computation of statistics over each candidate split, and these are simply too expensive to compute in real time, especially given the number of squares in our recursively defined tree! Instead, we precompute support structures that allow the necessary statistics to be computed in constant time. We request a particular set of structures, but we leave it as a puzzle for you to figure out how to use them to get the info you need.

The toqutree class is a standard quadtree class, with a twist. We consider a square image to be a torus or a donut, in the sense that the right side of the image is considered to be adjacent to the left, and the top of the image is considered to be adjacent to the bottom. We’ve defined the Node class for you, and a few other necessary memory management functions, but everything else is left to you. Since we will be grading both the .h and .cpp files, you are welcome to add helper functions to the class.

Getting the Given Code

Download the source files from pa3.zip, and follow the procedures you learned in lab to move them to your home directory on the remote linux machines.

Testing your code

We have provided two avenues for your exploration and testing, neither of which is sufficient to completely verify the correct implementation of all of your functions. You should add additional tests yourself!

When you type make two executables are produced. One depends on the given main.cpp, and the other depends on the file testComp.cpp which is a small collection of test cases using the catch framework (as in previous assignments).

Handing in your code

To facilitate anonymous grading, do not include any personally-identifiable information (like your name, your University ID number, or your cwl) in any of your source files. Instead, before you hand in this assignment, create a file called partners.txt that contains only the CSIDs of people in your collaboration partnership (if one exists), one per line. If you worked alone, include only your own CSID in this file. We will be automatically processing this information, so do not include anything else in the file. As always, if you’re working in a group, each group member must hand in the assignment. (Failure to cite collaborators violates our academic integrity policy;)

The following files are used to grade PA3:

stats.h
stats.cpp
toqutree.h
toqutree.cpp
partners.txt

All other files will not be used for grading.

You will submit your work to gradeScope as you did for PA2.

Good luck!

Homework 3

Tue, 19 Feb 2019 22:00:00 +0000

Link to document: hw3 overleaf | solutions

Instructions for HW3

This homework assignment allows you to work with a partner! Please submit only one copy of your work for the partnership. GradeScope allows you to identify both members of the pair upon submission.

A legible pdf of your solution must be checked in to GradeScope by the deadline.

Using Overleaf

Assignments will be distributed via Overleaf, an online latex editor. Before you begin, create an account and log in to Overleaf, then return to this page to link to the document. The initial document is read-only, so you’ll have to click on the up-arrow in the upper left corner of the screen to bring up your Overleaf dashboard. Then you can make a copy of the homework and begin to craft your solutions. We recommend that you use the Overleaf editor to typeset your answers to the problems. Then, when you’re finished, download your completed assignment as a .pdf, and upload it to Gradescope. (Detailed instructrions below.)

Latex is a powerful and popular typsetting package, commonly used for documents that have sophisticated diagrams and figures (like math and code!). The learning curve for fluency in Latex is fairly steep, but it’s a valuable skill, so we’re asking you to try to use it to compose your homework solutions. We are assisting your learning in three specific ways: 1) the homework’s latex source code contains examples of most of the tags you will need in your answers, 2) we are happy to answer any of your latex questions on piazza, and 3) the Overleaf web site has several short tutorials and videos to give you an overview of the kinds of things you can do. Like every latex user EVER, you will find google to be your best source of technical assistance.

Marking on Gradescope

Assignments will be collected and graded on [Gradescope]((https://gradescope.com/courses/33829). You will access GradeScope using your csid. We will be preloading the course roster into GradeScope, after which you will be able to log in.

NOTE: You will be required to follow the instructions below for submitting your assignments on Gradescope. The overall goal is for you to tell us, via the interface, where each of the problem parts appears on your submission. You MUST align the regions for every problem, even if your homeworks solution isn’t complete. We will not be able to mark any problem we can’t find.

Then follow the instructions found here: Gradescope Submission Guidelines.

Group Work

We highly encourage you to do assignments in groups of two, though you may work alone if you choose. Groups larger than two students are not allowed. Only one Gradescope submission is expected for each group. Be sure to identify your group on Gradescope.

Marking

As a rule of thumb,

A solution to a question that is correct, complete, and legible will be worth full marks.
A legible solution that contains some errors or is not quite complete, but shows a clear grasp of how the concepts and techniques required apply to this problem, will be worth about 66% of the marks.
A legible solution that is either correct but difficult to read, or contains errors or is not complete, but shows a clear grasp of the concepts and techniques required, although not their application to this problem, will be worth about 33% of the marks.
A solution that contains substantial errors, is far from complete, does not show a clear grasp of the concepts and techniques required, or is illegible will receive very few marks.

This marking scheme reflects our intent for you to learn the key concepts and techniques underlying computation, determine where they apply, and apply them correctly to interesting problems. It also reflects a practical fact: we have insufficient time to decipher illegible answers. All typeset solutions will be considered legible.

PA 2

Sat, 09 Feb 2019 00:00:00 +0000

GradeScope submission

We will be grading this PA using GradeScope. Our basic test cases will be run against your code every time you submit, so we encourage you to submit early and often! Code which does not compile will not be given any credit. Basic test cases will be available within a few days after the PA release. We will add the grading test cases sometime during the reading week.

Goals and Overview

In this PA you will:

learn about Stacks, Queues, and Deques
learn about depth-first-search (DFS) and breadth-first-search (BFS) traversal
learn about some more advanced C++ constucts, including basic templates and inheritance

Getting the Given Code

Download the source files from pa2.zip, and follow the procedures you learned in lab to move them to your home directory on the remote linux machines.

Part 1: The `Stack`, `Queue`, and `Deque` Classes

Template Compilation

Note that the stack.h, queue.h, and deque.h files we’ve given you include the .cpp files at the end, so you should NOT use a #include "XXX.h" at the top of the XXX.cpp file. We have done it this way so that the template types are instantiated appropriately.

The `Deque` Class

You will write a class named Deque which is a modification of a doubly ended queue structure. While the standard deque allows for insertion and removal at both ends of a contiguous arrangement of data, our deque will allow insertion and removal at one end, but only removal at the other. For convenience, we will refer to the removal-only end as the left end, and the other as the right.

Your deque should be implemented as follows: The underlying data structure will be a C++ standard vector. Following the convention of the queue we discussed in class, you will allow the data to “float” in the vector, with the following difference: If, upon a removal, you discover that the contiguous block of data (whose size is, say, k) will “fit” in the first k positions of the vector, then you should resize down by making a new vector and copying the k pieces of data into that new vector using the push_back function. Additions to the structure can use the standard vector functions, and can only occur at the “right” side of the contiguous data (i.e. the position of largest index). (Note that in this implementation the structure is not “circular”– we do not wrap the data using the modulo of the array size.)

The `Stack` Class

You will write a class named Stack that works just like the stack you heard about in lecture, with the addition of the peek() function. It is declared in the given file stack.h. You will implement it in stack.cpp.

Your Stack class must implement all of the methods mentioned in the given code. Please read the documentation in the header file to see what limitations we have placed on your Stack class and what the running times of each function should be.

The `Queue` Class

You will write a class named Queue that works just like the queue you heard about in lecture, with the addition of the peek() function. It is declared in the given file queue.h. You will implement it in queue.cpp.

Your Queue class must implement all of the methods mentioned in the given code. Please read the documentation in the header file to see what limitations we have placed on your Queue class and what the running times of each function should be.

Testing

We have provided a file testStackQueue.cpp which includes a few (albeit trivial) test cases that your code should pass if it is correct. To compile this executable, type:

make testStackQueue

These test cases are deliberately insufficient. We encourage you to augment this file with additional test cases, using the provided ones as examples. In particular, we have not provided test cases for your deque class. You will want to add those yourself!

Grading Information for Part 1

The following files are used to grade the stack and queue classes:

deque.cpp
stack.cpp
queue.cpp
partners.txt

All other files (including any testing files you create) will not be used for grading.

Part 2: Flood Fill

For this part of the assignment, you will be writing a number of functions that execute a “flood fill” on a PNG image. To flood fill a region of an image, you specify a point on the image and a fill color (or pattern) and all points similar in color and adjacent to the chosen point are changed to the fill color (or pattern). We will implement two different fill algorithms and three different fill patterns. The two fill algorithms are animated in the pictures above with a rainbow color fill pattern that we implemented.

Functors

Your first task in this part of the project is to implement the mechanism by which colors are selected for the fill pattern. To do this, you will create function objects (or “functors”) which will be passed into the fill algorithm and applied to pixels in a PNG. Specifically you will be making two new functors, each of which will be derived classes of the abstract base class called colorPicker, which is provided and described in the given code file colorPicker.h. We have also given you an example functor so you can see how things are supposed to work. Our functor is called rainColorPicker. The colorPicker base class has one purely virtual function that you must implement in your derived classes, but you may add others if you wish. In particular, you should expect your derived class constructors to initialize the functor with situation-dependent variables.

The purpose of any colorPicker is to take an image coordinate as its (x,y) parameters to operator(), and return the color it would suggest the client recolor the source PNG to. So in the examples above, the colorPicker is returning rainbow colors, based on the number of iterations in the fill algorithm.

Your task is to implement the stripeColorPicker and borderColorPicker and customColorPicker function objects. Refer to the given code for implementation details: they must overwrite the abstract operator()!

stripeColorPicker The first pattern will be a simple stripe flood fill. Its behavior is described in the given code, and sample images are given.
borderColorPicker The second fill pattern will leave most of the region unchanged, but it will draw a border around the edge of the region. Again, the specification is described in the given code.
customColorPicker The third exercise will be a fill pattern of your own creation!! You must create files customColorPicker.h and customColorPicker.cpp to change the pixels in the fill using some interesting pattern you design. You’ll also give us the .gif images created by your custom work. Note that we’ll leave it to you to figure out how to change your Makefile, filler.h, and filler.cpp to accommdate the new color picker.

The Fill Algorithms

The animations in the .gif images above are the result of breadth-first-search (BFS) and depth-first-search (DFS), respectively, both with a rainbow fill. We have given you the rainbow fill functions as an example for the others.

You will be implementing both DFS and BFS, each with the three different fill patterns described above.

You must implement all of the functions inside the filler namespace. Refer to the documentation in the header file for implementation details.

Testing

ImageMagick

Note that you must have ImageMagick installed if you’re developing on your personal machine. You can test for this requirement by running

convert

in your terminal. Windows users should visit ImageMagick to download the latest binary. OSX users can use homebrew or MacPorts to install it if missing. Linux users likely already have it installed. If not, then you can install it via your system’s package manager.

We have provided a file testFills.cpp which includes several test cases that your code should pass if it is correct. To compile this executable, type:

make testFills

This will create executable testFills.

One important thing to note about this PA is that the .gif compression may take some time. In general, on the remote machines via ssh, the solution code runs in somewhere from 5-20 seconds when all the tests are enabled and completed and the server is under a light load. It is advisable to comment out the tests for things you have already completed, so that you don’t have to wait as long (and use the CPU up) for things you already did. That said, the main point is that if you code doesn’t finish immediately don’t fret. Also note that as more traffic is happening on the server things will slow down. This may be an incentive to not wait until the last minute and have to try to run your code when everyone else is too!

The testFills program will generate images and animated gifs in the images/ folder, which can be diffed with the solution images in soln_images/. For animated gifs, the frames making up the animation are placed in frames/, and can be diffed with their corresponding expected frames in soln_frames/.

You can check your color picker outputs by redirecting testFills’ output to a file and diffing that with our solution output:

./testFills all > testFills.out
diff testFills.out soln_testFills.out

You can also diff each frame created for the animation, which will probably be useful for debugging:

diff frames/bfssolid00.png soln_frames/bfssolid00.png

These test cases are deliberately insufficient. We encourage you to augment this file with additional test cases, using the provided ones as examples.

Handing in Your Code

To facilitate anonymous grading, do not include any personally-identifiable information in any of your source files. Instead, before you hand in this assignment, create a file called partners.txt that contains only the CSIDs of people in your collaboration group (if it exists), one per line. If you worked alone, include only your own CSID in this file. We will be automatically processing this information, so do not include anything else in the file. If we must manually correct your submission, you may lose points. As always, if you’re working in a group, each group member must hand in the assignment. Failure to cite collaborators violates our academic integrity policy; we will be aggressively pursuing such violators.

You will submit your work to gradeScope as you did for PA1.

Grading Information

The following files are used to grade PA 2:

deque.cpp
stack.cpp
queue.cpp
stripeColorPicker.cpp
stripeColorPicker.h
borderColorPicker.cpp
borderColorPicker.h
customColorPicker.cpp
customColorPicker.h
filler.h
filler.cpp
customDFS.gif
customBFS.gif
partners.txt

All other files will not be used for grading.

Good luck!

Homework 2

Sun, 27 Jan 2019 12:00:00 +0000

Link to document: hw2 overleaf | solutions

Instructions for HW2

A legible pdf of your solution must be checked in to GradeScope by the deadline.

Using Overleaf

Marking on Gradescope

Then follow the instructions found here: Gradescope Submission Guidelines.

Group Work

Marking

As a rule of thumb,

A solution to a question that is correct, complete, and legible will be worth full marks.
A legible solution that contains some errors or is not quite complete, but shows a clear grasp of how the concepts and techniques required apply to this problem, will be worth about 66% of the marks.
A legible solution that is either correct but difficult to read, or contains errors or is not complete, but shows a clear grasp of the concepts and techniques required, although not their application to this problem, will be worth about 33% of the marks.
A solution that contains substantial errors, is far from complete, does not show a clear grasp of the concepts and techniques required, or is illegible will receive very few marks.

PA1

Fri, 11 Jan 2019 12:00:00 +0000

Lab machines

We will be grading the PAs for this course using the remote Linux machines. Any errors that you run into as a result of developing your code on other machines are your own responsibility.

Goals and Overview

In this PA (Programming Assignment) you will:

learn about the course programming environment
learn about vectors
learn about pointers
learn about linked lists
learn about management of dynamic memory

The Assignment, Part 1: Reading and Understanding the Policies

Read and understand the following information:

Important Information

The information in these links is relevant to not just this PA, but every future PA as well, and you will be held responsible for having read and understood all of the information. So, part of this PA assignment is to read over this part 1 material, and to gain a complete understanding of it before moving on to part 2 of this assignment. This means that you should ASK QUESTIONS ON ANY OF THIS PART 1 MATERIAL THAT YOU DO NOT UNDERSTAND.

The Assignment, Part 2: Coding

Problem Specification

A Linked List is a dynamic linear structure designed to hold any type of data. In this exercise, we develop and use a linked list to manipulate blocks of pixels from an image.

We have broken the image below into 6 Blocks.

Each Block is placed into a Node of a Chain, as shown here:

The Chain can be rearranged, and the image reassembled to create fascinating visual results.

We have provided a starting point for achieving this functionality. It is your task to complete and expand on our implementation.

Specifications for each function you write are contained in the given code. The list of functions here should serve as a checklist for completing the exercise.

In `block.cpp`

int width() const; Returns the width of the current block.
int height() const; Returns the height of the current block.
void build(PNG & im, int column, int width); From im, grabs the vertical strip of pixels whose upper left corner is at position (column,0), and whose width is width.
void render(PNG & im, int column ) const; Draws the current block at position (column,0) in im.
void greyscale(); This function changes the saturation of every pixel in the block to 0, which removes the color, leaving grey.

In `chain.cpp`

void clear(); Helper function for destructor and assignment operator.
void copy(const Chain & other); Helper function for copy constructor and assignment operator.
~Chain(); Destructor.
void insertBack(const Block & ndata); Insert a new node at the end of the Chain.
void moveBack(int startPos, int len, int dist); Move len nodes from startPos toward the end of the Chain, shifting by dist positions.
void roll(int k); Move k nodes from the end of the Chain to the front. Their order does not change.
void reverseSub(int pos1, int pos2); Reverses the order of the nodes in the chain from pos1 to pos2, inclusive.
void weave(Chain & other); consumes the nodes in other placing them in alternating positions in the current Chain. In the final chain, the original Chain will occupy the odd nodes, and the nodes from other will be in the even positions.

Implementation Constraints and Advice

We will be grading your work on functionality, efficiency, and memory use. All Chain functionality, aside from the insert and the copy functions, can be achieved by moving existing nodes, rather than by allocating new ones and/or making copies. If you are tempted to use the new function when you are manipulating the Chain, ask yourself if you can achieve your goal by reassigning pointers, instead.

The Chain structure is a circular doubly-linked list with one head sentinel. The sentinel is simply a place-holding Node, whose purpose is to define the start (and end) of the list. An empty list is simply a sentinel node whose next and prev pointers both point to itself. This creates a simplifying invariant: every Node containing data is guaranteed to have a node both before and after it. This invariant eliminates the special cases typically associated with the front and end of lists, thereby reducing the number of conditionals in your code. In our solution for chain.cpp, we have fewer than 3 conditionals involving pointers!

Finally, you’ll note that we are asking you to implement special memory management functions for the Chain class. You should ask yourself why we have not made similar requests for the Block class. Why doesn’t it need a destructor, copy constructor, or assignment operator?

Getting the Given Code

Download the source files from pa1.zip, and follow the procedures you learned in lab to move them to your home directory on the remote linux machines.

Handing in your code

To facilitate anonymous grading, do not include any personally-identifiable information (like your name, your University ID number, or your cwl) in any of your source files. Instead, before you hand in this assignment, create a file called partners.txt that contains only the CSIDs of people in your collaboration partnership (if one exists), one per line. If you worked alone, include only your own CSID in this file. We will be automatically processing this information, so do not include anything else in the file. (If we must manually correct your submission, you may lose points.) As always, if you’re working in a group, each group member must hand in the assignment. (Failure to cite collaborators violates our academic integrity policy;)

The following files are used to grade PA1:

block.cpp
chain.cpp
chain.h
partners.txt

All other files will not be used for grading.

Detailed instructions for handing in your work will be added to this page within the next few days.

Good luck!

Homework 1

Fri, 04 Jan 2019 08:00:00 +0000

Link to document: hw1 overleaf | solutions

Instructions for HW1

A legible pdf of your solution must be checked in to GradeScope by the deadline.

Using Overleaf

Marking on Gradescope

Then follow the instructions found here: Gradescope Submission Guidelines.

Group Work

Marking

As a rule of thumb,

A solution to a question that is correct, complete, and legible will be worth full marks.
A legible solution that contains some errors or is not quite complete, but shows a clear grasp of how the concepts and techniques required apply to this problem, will be worth about 66% of the marks.
A legible solution that is either correct but difficult to read, or contains errors or is not complete, but shows a clear grasp of the concepts and techniques required, although not their application to this problem, will be worth about 33% of the marks.
A solution that contains substantial errors, is far from complete, does not show a clear grasp of the concepts and techniques required, or is illegible will receive very few marks.

Mps on CPSC221 2018W2: Data Structures

PA3

Goals and Overview

The Assignment, Part 1: Inspiration and Background

QuadTrees on a Torus

Entropy

The Assignment, Part 2: Coding

Problem Specification

In class stats:

In class toqutree:

Implementation Constraints and Advice

Getting the Given Code

Testing your code

Handing in your code

Good luck!

Homework 3

Instructions for HW3

Using Overleaf

Marking on Gradescope

Group Work

Marking

PA 2

Goals and Overview

Getting the Given Code

Part 1: The Stack, Queue, and Deque Classes

The Deque Class

The Stack Class

The Queue Class

Testing

Grading Information for Part 1

Part 2: Flood Fill

Functors

The Fill Algorithms

Testing

Handing in Your Code

Grading Information

Good luck!

Homework 2

Instructions for HW2

Using Overleaf

Marking on Gradescope

Group Work

Marking

PA1

Goals and Overview

The Assignment, Part 1: Reading and Understanding the Policies

The Assignment, Part 2: Coding

Problem Specification

In block.cpp

In chain.cpp

Implementation Constraints and Advice

Getting the Given Code

Handing in your code

Good luck!

Homework 1

Instructions for HW1

Using Overleaf

Marking on Gradescope

Group Work

Marking

In `class stats`:

In `class toqutree`:

Part 1: The `Stack`, `Queue`, and `Deque` Classes

The `Deque` Class

The `Stack` Class

The `Queue` Class

In `block.cpp`

In `chain.cpp`