CMSC 216 Project #1 Solved

This is a short first project to allow you to get practice with the code development facilities that are different in this course than what you are used to in Java and Eclipse. This description is very lengthy relative to the amount of code you will need to write, because the first project has to explain the procedures used in all of the remaining ones. The actual explanation of the functions to be written is just over a page of this assignment, and the functions are simple.

Read the entire project assignment carefully, and look at the public tests described below, before starting to code.

To encourage (or require) you to write your own tests of your code, almost all the credit for this project will be for secret tests. There are only three public tests, worth 10 points total, which exist mostly just so you can verify that your code compiles on the submit server. (There are cases where code can work perfectly on the Grace systems yet not even compile on the submit server.) Since there are only three public tests, which each only test one thing, if you want to know whether your code is right you will have to do what every professional who writes code as part of their job has to do to know whether their code works, which is to write your own tests to check your code’s correctness. If you aren’t sure how to write your own tests you are welcome to ask in the TAs’ office hours.

Keep in mind that your tests of your code are part of your coursework for this project, which must be done individ-ually. Exchanging tests or test data with anyone else, or writing student tests together, is cheating and will be referred to the Office of Student Conduct. (See Appendix D below.)

All projects in this course assume you set up your account correctly in discussion section just before this project was assigned. As explained then, the command check-account-setup should tell you whether your account is set up correctly or not.

Be sure to carefully read course project policies handout on ELMS (on the Administrative and resources page) It describes in detail how projects are graded, which submission will be graded if you submit more than once, etc. Another handout on the same page describes the programming style that you should be using in projects, and how projects will be graded for style. Although this project is not being graded for style future projects will be, so you should read that handout carefully as well. Also carefully read the constraints in Appendix C, because you are only allowed to use certain C language features in writing the project.

Due to the size of the course it is not feasible for us to be able to provide project information or help via email/ELMS messages, so we will be unable to reply to such questions. However you are welcome to ask any questions verbally during the TAs’ office hours (or during, before, or after discussion section or lecture if time permits).

2    Development procedure

2.1    Obtaining the project files

The starting code for all projects in this course will be in a compressed tarfile; for this project the tarfile is named project01.tgz, and it is located in the public class directory ~/216public/project01. The UNIX/Linux tape archiver program tar is used to save data on backup tapes, but it can also combine and store separate files into a single file called a tarfile, which is what we used it to do with the starting files for the project. A tarfile is analogous to a zipfile, which you are presumably familiar with, except tarfiles are generally UNIX–specific. The convention is that the filename extension .tar is used for tarfiles created by tar, and the tarfiles that, to save disk space, are also compressed (using a utility called gzip) have the extension .tgz.

    • To obtain the project files log into grace.umd.edu and use the command cd ~/216 at the prompt.

This command will change your current directory to your special course disk space. (When your account was set up, a symbolic link named ~/216 should have been created, assuming your account was properly set up, otherwise nothing written here is going to be able to work.) You must write all of your projects in this course in your course disk space, so this command will always be the first one to use when doing any work on a project.

    • Then extract the files from the tarfile located in the public class directory using the command


tar -zxvf ~/216public/project01/project01.tgz

© 2023 L. Herman; all rights reserved    1
The z in -zxvf tells tar to uncompress the tarfile, x tells it to extract the files, v says to list the files as they are extracted, and f indicates that the next thing in the command is the name of the tarfile to operate upon. This will create a subdirectory in the current directory named project01 that contains the following files for the project:

functions.h:  This is a header file containing prototypes of the functions you need to write.

functions.c: This is a source file containing skeletons of the functions you need to write, which are described in Section 3 below. This is the only file that you should modify.

public1.c, public2.c, and public3.c: These are the three public tests for this project, which each contain a main() function that calls the functions you will write in functions.c.

.submit:  This is a hidden file that will allow you to submit your code to the CMSC project submission server.

Note that tar -ztvf ~/216public/project01/project01.tgz will list the files in the tarfile without actually extracting them, which is what the t instead of x in the argument following tar in the command tells it to do.

Once you have extracted the files from the tarfile once do not do it again later– that would just clobber whatever work you have done on the project by replacing it with the original tarfile contents. (If you think you need to extract the files from the tarfile again for any reason first talk with the TAs about it in their office hours, to find out of this is necessary, as well as for them to help you do it safely if it is actually needed.)

    • Now use the command cd project01 to change to the new subdirectory where the project files are. Use the text editor (e.g., Emacs) to edit functions.c and write the functions whose skeletons are in it.

If you happen to accidentally delete or make incorrect changes to your functions.c file, note that the UNIX tutorial explains how Emacs creates backup files that you can use to recover the most recently saved version.

2.2    Compiling your code and running it on the public tests

After you have written the functions described in Section 3 here is how you can compile your code with the public tests that are testing them (or with tests that you write). However, before you compile your code for the first time, use the cp

command to make a backup copy of your code with a different name, just for safety in the unlikely case you were to make any mistakes that would clobber the work you’ve done so far. (Appendix C discusses this further.)

To keep things simple for this project we won’t use separate compilation or the make utility (both to be covered in class later; don’t worry if you don’t even know what these are now). You can use the command gcc public1.c functions.c -o public1.x to compile your code for the first public test. (In discussion section you should have seen a convenient way to run the compiler via Emacs, which you can use instead if you like.)

The option -o public1.x causes the compiler to use the filename public1.x for the executable version of the program (which will be created if there are no syntax errors in your code), rather than the name a.out that it uses by default. (You can use a different executable name if you want.)

Due to how you set up your account an alias for gcc is added that automatically includes in the compilation com-mand the options below, which are required for projects in this course. If they aren’t used your code may not work when submitted to the project submission server, even if it works fine when you compile and run it on the Grace systems.

-ansi causes the compiler to recognize only programs that follow the first standard version for C, originally published by the American National Standards Institute.

-pedantic-errors will cause the compiler to strictly enforce the ANSI standard, and reject programs that do not follow it with errors rather than warnings.

-Wall turns on checking for many questionable programming constructs, so gcc will issue warnings for them.

-fstack-protector-all checks for one specific type of common error in C that is not checked by the above options, and is not explained further here, as it involves concepts that have not been covered yet.

-Werror causes the compiler to treat all warnings (including the ones enabled by -Wall) as errors.

To run the compiled executable program and check its results, just use its name as a command, so if you used the exact compilation command above, just type public1.x as a command. If your function is right and the test passes, “This test has passed!” will be printed, while if your function returned the wrong result, causing the test to fail, you will see an error message about a failed assertion.

© 2023 L. Herman; all rights reserved    2
If you change your code and want to compile it again you can retype the compilation command in the second paragraph in this section, but if you press the up–arrow key it will cycle through previously–typed commands, and you can re–execute the compilation command when it is shown again by just pressing return.

When you want to compile your code with the second public test, use the same command except substituting public2 for public1. This can be done conveniently just using the up–arrow key to retrieve the compilation command, and the left–arrow key to move back and change it to:

gcc public2.c functions.c -o public2.x

Then run public2.x. You can tell what each public test is testing by looking at its code, as well as by reading the comment at the top. And if you want to compile your code with one of your own tests– suppose one that’s named student1.c instead of public1.c– you can use a command like gcc student1.c functions.c -o student1.x, after which (assuming there are no syntax errors) you would just run student1.x as a command.

3    Project description

All you have to do is to write (in the file functions.c) the three fairly simple functions described below, which only require using basic C features: variables, expressions, conditional statements, and loops. They don’t even need arrays. The functions just return values based on their parameters– they do not read any input, or produce any output. You can calculate their results however you want, except that, as Appendix C says, you cannot use any C library functions in implementing your functions. (Read that sentence again, and be sure not to forget it.)


3.1    short compare_rectangles(int l1, int w1, int l2, int w2)

This function is given the length and width of two rectangles (l1 and w1 are the length and width respectively of the first rectangle, and similarly l2 and w2 for the second rectangle), and it should return a value indicating how their areas compare. The function should return:

    • 0 if the two rectangles have equal areas.

    • −1 if the first rectangle’s area is less than the second rectangle’s area.

    • 1 if the first rectangle’s area is greater than the second rectangle’s area.

    • It is an error case for any dimension to be negative (this doesn’t make sense). So if any of the parameters are less than zero the function should return −2.

Note that having a dimension of zero (or both dimensions of zero) is fine and not an error case, because a dimension of zero does make sense. In this case the rectangle will just have an area of zero and 0, −1, or 1 should be returned, depending on the area of the other rectangle.

3.2    int ith_factor(int a, int b, int i)

This function should return the i’th common positive factor of its parameters a and b, or −1 if they do not have at least i common factors.

For example, suppose a is 6240 and b is 288 (or, equivalently, a is 288 and b is 6240). Their first positive common factor is obviously 1, because 1 is a factor of any number, so if i is 1 the function should return 1. Their second common factor is 2 because 2 is a factor of both of these numbers, so if i is 2 then 2 should be returned. Their third common factor is 3 and their fourth common factor is 4, while their fifth common factor is 6, so if i was 5 the function should return 6. Their twelfth common factor is 96, so if i was 12 the function should return 96. These values of a and b do not have any common factors larger than 96 so −1 should be returned for them if i has any value greater than 12.

Note that negative numbers have positive factors, so for example ith_factor(624, 48, 7) = ith_factor(-624, 48, 7) = ith_factor(624, -48, 7) = ith_factor(-624, -48, 7) = 12. However, there is no such thing as the zero’th common factor of two numbers, and there is no meaningful interpretation of what the result should be if i was negative, so the function should return −1 if i is zero or less than zero.

Mathematically we could say that any number is a factor of zero. However, we only want the function to determine and return the i’th factor of values of a and b that are nonzero. So if either of a or b are zero then −1 should just be

© 2023 L. Herman; all rights reserved    3
returned. (Note that this is the behavior that the function will likely produce naturally if you write it to handle the cases above, so if it’s not necessary to handle this as a special case you should not do so.)

3.3    long pell(short n)

The Pell number sequence is used in mathematics to approximate the square root of 2, as well as to solve some other numerical problems. Pell numbers can be expressed in different ways but the simplest way is:

pel l (n) =

0
if n is 0


1
if n is 1






2 × pel l (n − 1) + pel l (n − 2)
for any n greater than 1




For example, pel l (0) (the first Pell number) is 0, pel l (1) is 1, pel l (2) is 2, pel l (3) is 5, pel l (4) is 12, and pel l (5) is

29.

Pell numbers can be computed recursively, based on the definition above, but they can also be computed iteratively as well, using a loop with two variables that store the values of the two previous Pell numbers at every iteration.

The Pell number sequence starts at 0 (meaning pel l (0)). It is not defined for negative numbers. So if n is negative the function should just return −1 to indicate that this is an error case.

You can calculate Pell numbers however you want, provided that (just like for the previous functions) you do not use any C library functions. But because the sequence of Pell numbers grows exponentially, there is a limit to how large you can calculate them. If you write the function in the most obvious way it would start taking prohibitively long to run on the Grace machines if it was called on values of n that were getting close to 50. (For example, coding the function in this way takes around a minute to compute pel l (50) on Grace.) So we will not test your function on any value of n greater than 45. (So you do not need to waste time trying to test your function yourself for values of n greater than 45.)

Note that it is possible to write the function efficiently, so it will work fast on values of n greater than 45. But if you do so and try to call it on arguments that are sufficiently large you will get an incorrect result. For example, pel l (115) is 6,623,843,019,776,607,541 (and if you don’t believe me you can calculate it by hand and see), but when I call my function to compute pel l (116) the result returned is −7, 884, 135, 764, 956, 931, 236, which is wrong. We will discuss in lecture shortly why this occurs. But you do not need to worry about (or test yourself) what results your function produces for any arguments that would cause such behavior, because as mentioned above we will just not test your function on any values of n larger than 45.

Note that the format specifier %ld prints a value of type long so you will have to use it if you want to print the value returned by your function during development or debugging.

Remember, you cannot use any C library functions at all in writing your functions for this project.

    • Submitting your code

Before you submit your code you must first make sure that it passes the few public tests, by compiling and running them yourself, as explained in Section 2.2 above. After that, submit using the single command submit in your project01 directory. This will prompt you for your UMD directory ID (not your nine–digit UID) and password, send your code to the CMSC project submission server, and inform you if the submission succeeded– which only means that your code was successfully received by the submit server, not whether it worked right there. You must then log into the submit server at https://submit.cs.umd.edu/spring2023 (also linked to from ELMS, under Pages → Administrative and resources), and check whether your program worked right on the public tests there also. Some notes:

    • If you are trying to submit but the submission fails with a message about your ID or password being wrong then try logging into the submit server by clicking on the link above:

– If you can’t submit and cannot log into the submit server at that link via your web browser, and you only recently added the course, then just wait a day and try again. I will check every day or so and activate new students in the submit server. (Note that the TAs cannot activate you in the submit server.)

– If you can’t submit and can log into the submit server at that link via your web browser then something could be wrong in your account setup (that was done during discussion section). Run check-account-setup and come to the TAs’ office hours for help if you can’t fix any problems that it identifies on your own.

© 2023 L. Herman; all rights reserved    4
(If you are trying to submit and get a message that ends with the line “You did not provide enough argu-ments.” then your account setup is definitely wrong.)

    • If you can submit and your code compiles on Grace but does not on the submit server, you may have changed the header file functions.h which you were not supposed to do, or something in your account setup may be wrong.

    • Do not wait until the last minute to submit your program. The submission server enforces deadlines strictly. Even one second beyond the time at the top of the first page of this assignment means that your project is late. You are urged to finish projects early. Finishing at least one day before its deadline will allow time to reread the project requirements, and ensure you have not missed anything that could cause you to lose credit, or to make any necessary changes if you have.

Illness does not justify project extensions unless it is extremely severe, and lasts most or all of the time that a project is assigned (see the course syllabus).

    • If this is your first CMSC programming course here and you aren’t familiar with the submit server, you can ask in the TAs’ office hours for help understanding it, and what information it’s showing.

    • Do not submit projects using the submit server’s mechanism for uploading a zipfile or individual files. You must use the submit command to submit, or for reasons described in the project policies handout mentioned above you may end up losing significant credit on the project.

    • Do not make unnecessary submissions of the project, or you may lose credit. (See the project policies handout on ELMS for details.) To avoid losing credit, do not submit this project more than five times. I suggest rereading this entire assignment again before submitting, to ensure you didn’t miss anything important.

    • Do not use the submit server to keep backups of your project code. Having a large number of unnecessary sub-missions just slows the submit server down for everyone. Instead use UNIX commands (see Appendix C below) to frequently make copies of your project files, with different filenames or in different directories. Similarly, do not use the submit server to check if your program compiles, or to check its results on the public test. You should be compiling and testing your code yourself, as described above, before submitting.

B    Grading criteria

Your grade for this project will be based on:

public tests
10 points


secret tests
90 points



Since secret tests are 90% of your score for the project be sure to test your functions carefully and thoroughly on special/edge cases, to be able to get a good grade.

Secret tests and their results will not available until the project grading has been finished. The few public tests are obviously not comprehensive, and you will need to do testing on your own to ensure the correctness of your functions.

Your own (student) tests will not be graded in projects in this course, as they may have been in CMSC 131 and 132. Writing your own tests is for you to make sure your code is right, so you will be able to get good scores on the secret tests.

    • Other notes

        ◦ You will lose credit if you use any features of C that are not allowed in writing the project:

– You may use the features of C that have been covered up through the day that this project is being assigned. (Even if C features are covered in the textbook you cannot use them unless they were covered in class up through when the project is assigned, except for what is allowed by the next two items.)

– You may use any C operators covered in Sections 5.1.4 through 5.1.8 of the Reek text– these are mostly the same as in Java so they will not be discussed in detail in lecture except for where they differ from Java.


© 2023 L. Herman; all rights reserved    5
– You may use any C features in Chapter 4 of the textbook, most of which will also be skipped in class because they are also similar to Java. The one exception is that you cannot use the goto statement mentioned in Chapter 4.

– You may not use any C library functions at all in writing your code. The project can be written using only the features of C covered so far, without needing any C library functions.

    • Your code for this project must all be in the single source file functions.c, otherwise it will not compile when submitted, so do not rename it or split it up. Do not add any new source or header files to the project. Also do not move functions.c elsewhere– it must remain in the project01 directory to work right on the submit server.

Do not write your functions in the header file functions.h, or modify it at all, because your code will definitely not compile on the submit server if you do.

    • If you get the error “Segmentation fault” when running your program this means it had a fatal error. For the moment, the best way to debug errors is to just add debug printf() statements to your code, to print the values of the variables that are being used. Note that for technical reasons to be discussed later in class, the last thing printed by every debug printf() should be a newline, to ensure its output appears correctly.

If you do need to add printf() statements during debugging be sure to remove them before submitting, because they could throw off the results and make it appear to the submit server that your results are wrong.

    • Besides the few public tests you should write your own tests for your code! If you have a problem or bug and have to come to the TAs’ office hours, you must come with tests that illustrate the problem (meaning you must write tests of your own, different than the public tests). In particular you will need to show the smallest test you were able to write that illustrates the problem, so whatever the cause is can be narrowed down as much as possible before the TAs even start helping you. (The submit server does not run your own tests for C projects, as it may have in Java projects in the prior courses.)

But don’t modify the public tests, otherwise you won’t be testing your code on the cases that the submit server is running. Just create your own tests.

    • Note that the project policies handout says that all your projects must work on at least half of the public tests (by the end of the semester) in order for you to be eligible to pass the course. (See the project policies handout for full details.) But since the public tests are worth only 10 points you won’t get a good score on the project unless you test your functions yourself to make sure they work right in other cases.

    • As the UNIX tutorial discusses, a wireless network can be slow when running a graphical program like Emacs. If you are able to get a wired Ethernet cable and do work with your computer connected to an Ethernet jack (either a wall jack or one on the back of your wireless router), things will be much faster. On a slow connection, using “emacs -nw” will be much faster (see the tutorial).

    • If you happen to be familiar with them, don’t use nano or pico for editing programs. These are very small and limited text editors intended for editing short emails. There are several full–featured text editors available on Grace. Emacs is generally similar to nano and pico but it has far more capabilities.

    • It’s possible for a program to work fine on one machine (like the Grace machines), but not work at all on another machine (like the submit server), and this may occur more frequently in C, due to the nature of the language. Consequently you must log into the CMSC project submission server and see whether your code worked there after you submit it.

If you haven’t taken classes using the CMSC submit server before you can go to the TAs’ office hours and ask them show you how it works.

    • If your code is passing tests on Grace but not on the submit server, the first thing to do is to check whether you are using any uninitialized variables, which is the most common error that is made in this class.

    • Keep backup copies of your project and any other important files (like your own tests) in a different directory in your course disk space than where your project is. It’s a good idea to save backup copies every time you log in or log out, if not more frequently. Recall from the first discussion sections and the UNIX tutorial that the -r


© 2023 L. Herman; all rights reserved    6
option to cp will make a copy of a whole directory and all its contents, so a command like cp -r project01 project01.bak would make a new directory containing a copy of everything in the project01 directory (this command assumes you are located above the project01 directory, e.g., cd ~/216 first). Then the next time you make a backup, use a different name (like project01a.bak, for example).

Furthermore, it’s important to save your work every few minutes in Emacs, so an unexpected power outage or lost network connection would only cause a small amount of work to be lost. Every time you save a file in Emacs it creates a new backup version, and having backup versions created frequently minimizes the loss of work if there is ever a problem and you need to use the most recent one.

Extensions will not be given on projects due to mistakes such as accidentally deleting your project work. You need to create backup files as described in the two preceding paragraphs as insurance in case you ever need them.

    • Academic integrity

Please carefully read the academic honesty section of the syllabus. Any evidence of impermissible cooperation on projects, use of disallowed materials or resources, publicly providing others access to your project code online, or unauthorized use of computer accounts, will be submitted to the Office of Student Conduct, which could result in an XF for the course, or suspension or expulsion from the University. Be sure you understand the academic integrity requirements in the syllabus. These policies apply to all students, and the Student Honor Council does not consider lack of knowledge of the policies to be a defense for violating them. More information is in the course syllabus– please review it now.

The academic integrity requirements also apply to any student tests for projects, which must be your own original work. Sharing student tests or test data, or working together to write them, is prohibited.









































© 2023 L. Herman; all rights reserved    7