Corning Community College
CSCS2330 Discrete Structures
~~TOC~~
Project: EXPLORING WEIRD NUMBERS (ewn0)
Objective
To apply your skills in implementing an algorithm that determines certain attributes of a number based on its factor composition.
Background: Numerology
In ancient times, numbers and properties of numbers carried certain mystical qualities. In the Pythagorean tradition (at least as history attributes it), we have the following classifications:
abundant number: a number wherein the sum of its factors is greater than itself
perfect number: a number wherein the sum of its factors is equal to itself
deficient number: a number wherein the sum of its factors is less than itself
There are two activities at play here:
the knowledge of the factors of a number (which we've had some experience with in our prime number endeavors)
the sum of those factors to make the above determination of attribute
We will be writing a program that will perform these actions for a range of numbers.
Program: Description and Specifications
You are to write a program that:
Grabit Integration
For those familiar with the grabit tool on lab46, I have made some skeleton files and a custom Makefile available for this project.
To “grab” it:
lab46:~/src/discrete$ grabit discrete ewn0
make: Entering directory '/var/public/SEMESTER/CLASS/ewn0'
‘/var/public/SEMESTER/CLASS/ewn0/Makefile’ -> ‘/home/USERNAME/src/CLASS/ewn0/Makefile’
‘/var/public/SEMESTER/CLASS/ewn0/ewn0.c’ -> ‘/home/USERNAME/src/CLASS/ewn0/ewn0.c’
make: Leaving directory '/var/public/SEMESTER/CLASS/ewn0'
lab46:~/src/discrete$ cd ewn0
lab46:~/src/discrete/ewn0$ ls
Makefile ewn0.c
lab46:~/src/discrete/ewn0$
Just another “nice thing” we deserve.
NOTE: You do NOT want to do this on a populated ewn0 project directory– it will overwrite files. Only do this on an empty directory.
Makefile fun
With the Makefile, we have your basic compile and clean-up operations:
make: compile everything
make debug: compile everything with debug support
make clean: remove all binaries
make save: make a backup of your project
make submit: submit project (uses submit tool)
Execution
Your program output should be as follows (given the specific inputs via the command-line):
lab46:~/src/discrete/ewn0$ ./ewn0 2 16
[2] deficient: 1 = 1
[3] deficient: 1 = 1
[4] deficient: 1+2 = 3
[5] deficient: 1 = 1
[6] perfect: 1+2+3 = 6
[7] deficient: 1 = 1
[8] deficient: 1+2+4 = 7
[9] deficient: 1+3 = 4
[10] deficient: 1+2+5 = 8
[11] deficient: 1 = 1
[12] abundant: 1+2+3+4+6 = 16
[13] deficient: 1 = 1
[14] deficient: 1+2+7 = 10
[15] deficient: 1+3+5 = 9
[16] deficient: 1+2+4+8 = 15
lab46:~/src/discrete/ewn0$
And we don't have to start at 2:
lab46:~/src/discrete/ewn0$ ./ewn0 37 42
[37] deficient: 1 = 1
[38] deficient: 1+2+19 = 22
[39] deficient: 1+3+13 = 17
[40] abundant: 1+2+4+5+8+10+20 = 50
[41] deficient: 1 = 1
[42] abundant: 1+2+3+6+7+14+21 = 54
lab46:~/src/discrete/ewn0$
Additionally, we can also do this:
lab46:~/src/discrete/ewn0$ ./ewn0 30 17
[30] abundant: 1+2+3+5+6+10+15 = 42
[29] deficient: 1 = 1
[28] perfect: 1+2+4+7+14 = 28
[27] deficient: 1+3+9 = 13
[26] deficient: 1+2+13 = 16
[25] deficient: 1+5 = 6
[24] abundant: 1+2+3+4+6+8+12 = 36
[23] deficient: 1 = 1
[22] deficient: 1+2+11 = 14
[21] deficient: 1+3+7 = 11
[20] abundant: 1+2+4+5+10 = 22
[19] deficient: 1 = 1
[18] abundant: 1+2+3+6+9 = 21
[17] deficient: 1 = 1
lab46:~/src/discrete/ewn0$
Submission
Project Submission
To submit this program to me using the submit tool, run the following command at your lab46 prompt:
lab46:~/src/discrete/ewn0$ make submit
removed 'ewn0'
Project backup process commencing
Taking snapshot of current project (ewn0) ... OK
Compressing snapshot of ewn0 project archive ... OK
Setting secure permissions on ewn0 archive ... OK
Project backup process complete
Submitting discrete project "ewn0":
-> ../ewn0-DATESTRING-HOUR.tar.gz(OK)
SUCCESSFULLY SUBMITTED
You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.
Submission Criteria
To be successful in this project, the following criteria must be met:
Project must be submit on time, by the posted deadline.
Early submissions will earn 1 bonus point per full day in advance of the deadline.
Late submissions will lose 25% credit per day, with the submission window closing upon reaching the 4th day following the deadline.
To clarify: if a project is due on Wednesday (before its end), it would then be 25% off on Thursday (day 1), 50% off on Friday (day 2), 75% off on Saturday (day 3), and worth 0% once it becomes Sunday (day 4).
Certain projects may not have a late grace period, and the due date is the absolute end of things.
all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).
Output generated must conform to any provided requirements and specifications (be it in syntax or sample output)
Processing must be correct based on input given and output requested
Specification details are NOT to be altered. This project will be evaluated according to the specifications laid out in this document.
Code must compile cleanly.
Code must be nicely and consistently indented (you may use the indent tool)
You are free to use your own coding style, but you must be consistent
Avoid unnecessary blank lines (some are good for readability, but do not go overboard- double-spacing your code will get points deducted).
Indentation will be rated on the following scale (worth 3 total points):
3/3: Aesthetically pleasing, pristine indentation, easy to read, organized
2/3: Mostly consistent indentation, but some distractions (superfluous or lacking blank lines, or some sort of “busy” ness to the code)
1/3: Some indentation issues, difficult to read
0/3: Lack of consistent indentation (didn't appear to try)
Code must be commented
Code must be appropriately modified
Appropriate modifications will be rated on the following scale (worth 3 total points):
3/3: Complete attention to detail, original-looking implementation
2/3: Lacking some details (like variable initializations), but otherwise complete (still conforms, or conforms mostly to specifications)
1/3: Incomplete implementation (typically lacking some obvious details/does not conform to specifications)
0/3: Incomplete implementation to the point of non-functionality (or was not started at all)
Implementation must be accurate with respect to the spirit/purpose of the project (if the focus is on exploring a certain algorithm to produce results, but you avoid the algorithm yet still produce the same results– that's what I'm talking about here).. worth 3 total points:
3/3: Implementation is in line with spirit of project
2/3: Some avoidance/shortcuts taken (note this does not mean optimization– you can optimize all you want, so long as it doesn't violate the spirit of the project).
1/3: Generally avoiding the spirit of the project (new, different things, resorting to old and familiar, despite it being against the directions)
0/3: entirely avoiding.
Error checking must be adequately and appropriately performed, according to the following scale (worth 3 total points):
3/3: Full and proper error checking performed for all reasonable cases, including queries for external resources and data.
2/3: Enough error checking performed to pass basic project requirements and work for most operational cases.
1/3: Minimal error checking, code is fragile (code may not work in full accordance with project requirements)
0/3: No error checking (code likely does not work in accordance with project requirements)
Track/version the source code in a repository
Submit a copy of your source code to me using the submit tool (make submit will do this) by the deadline.