CSC121H Winter 2018: Exercises

CSC121: Exercise 6

Due: Sunday, April 1st by 11:00pm

IMPORTANT NOTE: Make sure your e6.R does not have any errors when you 'source' it.
If any errors occur when sourcing the file, you will get zero.

What to hand in

Submit one file, which must be named "e6.R" (without the quotation marks). Exercises are to be done individually.

Check that file name!

Once you have submitted on MarkUs, be sure to check that you have submitted the correct versions; new or missing files will not be accepted after the due date. Spelling of filenames, including case, counts. If your file is not named exactly as required, your mark will be zero.

If you realize you have submitted an incorrectly named file, just fix the name and resubmit. There is no need to get rid of the wrongly-named file.

Watch that clock!

We will mark the newest version submitted not later than the deadline. Don't submit just once; instead, submit at least once well in advance, so that you know what you're doing, and then keep submitting new versions as you do more of the exercise. That way, if you run out of time on the last function that you just can't do, you'll still get marks for the others.

What to put in e6.R (A LITTLE DIFFERENT THIS TIME!)

Download e6_starter.R and rename it to e6.R. In this file, we have provided both the function header and the docstring for all the functions that you need to have in the file e6.R.

Notice how there are two classes in the starter code.
You will be completeing the constructors for these classes, as well as a bunch of functions that work with these classes.
Note that some functions are generic, some are meant to work with only one of the classes, and some may work with both classes but only need one definition. Make sure you understand what each function does and how it works with the structure of each class.

You need to write the function body for each of the functions to produce the correct output. You need to write these functions using proper R structure and style. Although we are not marking your style, it is important to have a look at at the R Style Guidelines and use them so that you create good habits. Use intermediate variables to help describe what your function is doing. Do not put your whole function into the return statement.

Example Test Run

Here is an example test run with a few objects created with the constructors. Note that your functions should work on any valid input arguments: Example Test Run

Important Instructions!

Remember, you are only submitting the function definitions. You do not need to submit any test cases or R Console output.

Like the name of the file itself, the names of the functions must be spelled exactly as shown. You should not change them.

Do not call print or cat in your functions, and do not write any code outside of the function definitions. Doing so may cause your code to fail the tests.

How to check your code

You will make mistakes! Be sure to check your functions by sourcing them in RStudio, and creating a separate R script for testing your function. Make some test cases (like we did in class and lab), and make sure your function works with different arguments. Ensure you get back what you expect when you call your functions. Do not just check the example test cases, but test the functions with test cases of your own too.

If you need help

Please make use of any of the resources listed here: Getting Help