Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS2330 Discrete Structures</fs></WRAP>
</WRAP>

======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:
  * 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:
      * if it is **NOT** a **semi-perfect** nor a **weird** number, we keep the format from the previous project:
        * <nowiki>[NUMBER] quality: F1+F2+...+FN = SUM</nowiki>
        * for example: <nowiki>[8]</nowiki> deficient: 1+2+4 = 7
      * if it **IS** a **semi-perfect** or a **weird** number, we specifically display that information:
        * <nowiki>[NUMBER] quality: F1+F2+...+FN = SUM (CLASSIFICATION: factor summation or "none")</nowiki>
        * for example: <nowiki>[12]</nowiki> abundant: 1+2+3+4+6 = 16 (semi-perfect: 1+2+3+6).
        * or: <nowiki>[70]</nowiki> abundant: 1+2+5+7+10+14+35 = 74 (weird: none).

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:

<cli>
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$ 
</cli>

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):

<cli>
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$ 
</cli>

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:

<cli>
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
</cli>

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.
      * 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.
Lab46 Wiki

User Tools

Site Tools

Page Tools
