Corning Community College
CSCS2330 Discrete Structures
~~TOC~~
Project: EXPLORING WEIRD NUMBERS (ewn1)
Objective
To continue to apply your skills in implementing an algorithm that determines certain attributes of a number based on its factor composition.
Background: Weird and Semi-perfect numbers
In the previous project, we explored the computation of abundant, perfect, and deficient numbers. There is one more in that “genre”, and that is the classification of weird numbers, with a related semi-perfect classification.
A semi-perfect number is a natural number that is equal to the sum of all or some of its factors. A semi-perfect number that is equal to the sum of all its proper divisors is a perfect number. So by this definition, semi-perfect numbers can be abundant or perfect numbers, but that is limited by the constraining requirement of some combination of sums equalling the number we are evaluating.
Some examples of semi-perfect numbers include:
6: with factors of 1, 2, 3, we see that 1+2+3 = 6. As this is also ALL the factors, this was identified as a perfect number in the previous project (and from the definition above, all perfect numbers are semi-perfect, but NOT all semi-perfect numbers are perfect).
12: with factors of 1, 2, 3, 4, 6, we see that 1+2+3+6 = 12. Adding up ALL the factors gives us a value greater than 12 (and in the previous project, it would have been classified as an abundant number).
18: with factors of 1, 2, 3, 6, 9, we see that 3+6+9 = 18. Adding up ALL the factors gives us a value greater than 18 (and in the previous project, it would have been classified as an abundant number).
A weird number is defined as a natural number that is abundant but not semi-perfect. In other words, the sum of the factors (divisors including 1 but not itself) of the number is greater than the number, but no subset of those divisors sums to the number itself.
Some examples of weird numbers include:
70: with factors 1, 2, 5, 7, 10, 14, 35, is an abundant number where the factors sum to 74. Yet there is no subset of factors that can be summed that give us a value of 70. Therefore, 70 is classified as a weird number.
Subset of sums
Calculating semi-perfect and weird numbers requires us to analyze the various combinations of factor sums. This requires some additional consideration in our implementation, as we need to try every possible combination to see if there is a match.
Program: Description and Specifications
You are to write a program (ewn1.c) that:
Basically, requirements are the SAME as for ewn0, only we are adding in the check, processing, and output identification of semi-perfect and weird numbers.
There exists the possibility that there may be multiple combinations of factor subset sums that will prove semi-perfection. For the purposes of this project, display the FIRST match you find (as such, you do not need to find EVERY possible combination, merely the first and then bail out of your attempt).
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 ewn1
make: Entering directory '/var/public/SEMESTER/CLASS/ewn1'
‘/var/public/SEMESTER/CLASS/ewn1/Makefile’ -> ‘/home/USERNAME/src/CLASS/ewn1/Makefile’
‘/var/public/SEMESTER/CLASS/ewn1/ewn1.c’ -> ‘/home/USERNAME/src/CLASS/ewn1/ewn.c’
make: Leaving directory '/var/public/SEMESTER/CLASS/ewn1'
lab46:~/src/discrete$ cd ewn1
lab46:~/src/discrete/ewn1$ ls
Makefile ewn1.c
lab46:~/src/discrete/ewn1$
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/ewn1$ ./ewn1 66 70
[66] abundant: 1+2+3+6+11+22+33 = 78 (semi-perfect: 11+22+33)
[67] deficient: 1 = 1
[68] deficient: 1+2+4+17+34 = 58
[69] deficient: 1+3+23 = 27
[70] abundant: 1+2+5+7+10+14+35 = 74 (weird: none)
lab46:~/src/discrete/ewn1$
As with ewn0, starting and ending at any acceptable value is possible, as well as the starting value being higher than the ending value.
Submission
Project Submission
To submit this program to me using the submit tool, run the following command at your lab46 prompt:
lab46:~/src/discrete/ewn1$ make submit
removed 'ewn1'
Project backup process commencing
Taking snapshot of current project (ewn1) ... OK
Compressing snapshot of ewn1 project archive ... OK
Setting secure permissions on ewn1 archive ... OK
Project backup process complete
Submitting discrete project "ewn1":
-> ../ewn1-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.