Project: EXPLORING WEIRD NUMBERS (ewn0)

To apply your skills in implementing an algorithm that determines certain attributes of a number based on its factor composition.

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
  • for example, in the number 12, we have:
    • the factors: 1, 2, 3, 4, 6
    • the sum thereof: 1 + 2 + 3 + 4 + 6 = 16
    • as 16 is greater than 12, 12 is considered an abundant number
• perfect number: a number wherein the sum of its factors is equal to itself
  • for example, in the number 6, we have:
    • the factors: 1, 2, 3
    • the sum thereof: 1 + 2 + 3 = 6
    • as 6 is equal to 6, 6 is considered a perfect number
• deficient number: a number wherein the sum of its factors is less than itself
  • for example, in the number 21, we have:
    • the factors: 1, 3, 7
    • the sum thereof: 1 + 3 + 7 = 11
    • as 11 is less than 21, 21 is considered a deficient number

There are two activities at play here:

1. the knowledge of the factors of a number (which we've had some experience with in our prime number endeavors)
2. 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.

You are to write a program that:

• accepts two values via command-line arguments
  • argv[1]: the starting value
  • argv[2]: the ending value
  • proper error checking should be performed so that the program cannot proceed (and should display an appropriate error) if the following conditions are encountered:
    • values less than 2 are provided, with an error “invalid range specification”
    • missing argv[2], with the error “missing upper bound”
    • missing both argv[1] and argv[2]: “insufficient data provided”
  • assumptions: as inferred in the error checking above, processing can start at 2, and proceed up to the maximum value of the data type.
    • while we are including 1 as a factor, we are not including the number itself in the list of factors.
  • perform the necessary calculations to determine the factors, from (and including) argv[1] through (and including) argv[2]
    • be sure to STORE the factors
    • sum the factors, and determine its abundant/perfect/deficient quality
    • NOTE: the starting value does NOT have to be less than the ending value. We are merely connecting the two.
  • display the results for that number, in the following format:
    • [NUMBER] quality: F1+F2+...+FN = SUM
    • for example: [8] deficient: 1+2+4 = 7

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.

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)

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$ 

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.

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.
    • Bonus eligibility requires an honest attempt at performing the project (no blank efforts accepted)
  • 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)
  • output obviously must also be correct based on input.
• 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.
  • Each source file must compile cleanly (worth 3 total points):
    • 3/3: no compiler warnings, notes or errors.
    • 2/3: one of warning or note present during compile
    • 1/3: two of warning or note present during compile
    • 0/3: compiler errors present (code doesn't compile)
• 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
  • Commenting will be rated on the following scale (worth 4 total points):
    • 4/4: Not only aesthetically pleasing, but also adequately explains the WHY behind what you are doing
    • 3/4: Aesthetically pleasing (comments aligned or generally not distracting), easy to read, organized
    • 2/4: Mostly consistent, some distractions or gaps in comments (not explaining important things)
    • 1/4: Light commenting effort, not much time or energy appears to have been put in.
    • 0/4: No original comments
    • should I deserve nice things, my terminal is usually 90 characters wide. So if you'd like to format your code not to exceed 90 character wide terminals (and avoid line wrapping comments), at least as reasonably as possible, those are two sure-fire ways of making a good impression on me with respect to code presentation and comments.
  • Sufficient comments explaining the point of provided logic MUST be present
• 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.