Corning Community College CSCS1320 C/C++ Programming ======Project: CALCULATING N-ARY VALUES (cnv0)====== =====Objective===== To create a program that can calculate and determine the number of factor pairs of a given number, starting with values composed of exactly 2 sets of factor pairs. =====GRABIT===== To assist with consistency across all implementations, data files for use with this project are available on lab46 via the **grabit** tool. Be sure to obtain it and ensure your implementation properly works with the provided data. lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT Please study any provided code, comments, or supporting documents, and look up, experiment, and ask questions on aspects that you do not understand. =====EDIT===== You will want to go [[/notes/cprog/fall2023/projects/cnv0|here]] to edit and fill in the various sections of the document: * [[/notes/cprog/fall2023/projects/cnv0|https://lab46.g7n.org/notes/cprog/fall2023/projects/cnv0]] {{page>notes:cprog:fall2023:projects:cnv0&nouser&nodate&nomdate}} =====Program===== It is your task to write a program that, upon accepting various pieces of input from the user, computes the number of factor pairs of a given number, displaying its eligibility as a secondary number. =====Specifications===== Your program should: * have valid, descriptive variable names of length //no shorter than// 4 symbols * have consistent, well-defined indentation (no less than 4 spaces per level of indentation) * all code within the same scope aligned to its indentation level * have proximal comments explaining your rationale (the why and how), throughout your code * to STDERR, prompt for the number (range appropriate of an unsigned long int) * properly store this in a variable of type **unsigned long int** * immediately after the input, check to make sure the input number is a positive number greater than or equal to 2; if in violation, display an error (to STDERR) and exit with a non-zero value. * proceed to evaluate the input number, determining whether or not it is a secondary (nary(2)) number. * if it is, display to STDOUT that it is a secondary number (see execution section below for message) * if it is not, display to STDOUT that it is not a secondary number (again, see execution section below) * using a single return statement at the conclusion of the code, return a 0 indicating successful operation Some additional points of consideration: * Note that the driving variables in your loops need to be at least of type **short int**, otherwise you may get a warning when you compile it. =====Process===== In general, you will be looking to do something like the following: DISPLAY PROMPT READ NUMBER SHOULD NUMBER BE LOWER THAN TWO: DISPLAY AN ERROR EXIT WITH A NON-ZERO STATUS SO LONG AS FACTOR IS LESS THAN NUMBER: SHOULD THE FACTOR BE A LEGITIMATE FACTOR OF NUMBER: INCREMENT COUNT OF FACTOR PAIRS SHOULD THIS NUMBER HAVE A SQUARE FACTOR: INCREMENT COUNT OF FACTOR PAIRS SHOULD THE NUMBER OF FACTOR PAIRS MATCH WHAT WE ARE LOOKING FOR: DISPLAY THAT NUMBER BEING PROCESSED IS OF THE NEEDED TYPE OTHERWISE: DISPLAY THAT THE NUMBER BEING PROCESSED IS NOT THE NEEDED TYPE =====Reference===== Copied as part of the grabit, inside your **cnv0/** subdirectory, will be a copy of my implementation (in executable form, by the name **ref_cnv0**), which abides by the project specifications. Please compare its output against that of your implementation. You can invoke the reference implementation by running the following: yourpi:~/src/SEMESTER/DESIG/cnv0$ make check Enter a number: 6 6 is a secondary number yourpi:~/src/SEMESTER/DESIG/cnv0$ =====Verification===== In addition, I have also placed a **cnv0verify** script in that same subdirectory, which will test your program against a range of values, to determine overall correctness. You can run the verify script using the Makefile, as follows: yourpi:~/src/SEMESTER/DESIG/PROJECT$ make verify [ 1] you have: err, should be: err [ 2] you have: no, should be: no [ 3] you have: no, should be: no [ 4] you have: yes, should be: yes [ 5] you have: no, should be: no [ 6] you have: yes, should be: yes [ 7] you have: no, should be: no [ 8] you have: yes, should be: yes [ 9] you have: yes, should be: yes [ 10] you have: yes, should be: yes [ 11] you have: no, should be: no [ 12] you have: no, should be: no [ 13] you have: no, should be: no [ 14] you have: yes, should be: yes [ 15] you have: yes, should be: yes [ 16] you have: no, should be: no [ 17] you have: no, should be: no [ 18] you have: no, should be: no [ 19] you have: no, should be: no [ 20] you have: no, should be: no [ 21] you have: yes, should be: yes [ 22] you have: yes, should be: yes [ 23] you have: no, should be: no [ 24] you have: no, should be: no [ 25] you have: yes, should be: yes [ 26] you have: yes, should be: yes [ 27] you have: yes, should be: yes [ 28] you have: no, should be: no [ 29] you have: no, should be: no [ 30] you have: no, should be: no [ 31] you have: no, should be: no [ 32] you have: no, should be: no [ 33] you have: yes, should be: yes [ 34] you have: yes, should be: yes [ 35] you have: yes, should be: yes [ 36] you have: no, should be: no yourpi:~/src/SEMESTER/DESIG/PROJECT$ =====SUBMISSION===== To successfully complete this project, the following criteria must be met: * Code must compile cleanly (no notes, warnings, nor errors) * Output must be correct, and match the form given in the sample output above. * Code must be nicely and consistently indented * Code must be well commented * Do NOT double space your code. Group like statements together. * Output Formatting (including spacing) of program must conform to the provided output (see above). * Track/version the source code in a repository * Submit a copy of your source code to me using the **submit** tool. ====Submit Tool Usage==== To submit this program to me using the **submit** tool, run the following command at your lab46 prompt: lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit And make sure you get no error messages. 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. =====RUBRIC===== I'll be evaluating the project based on the following criteria: 52:cnv0:final tally of results (52/52) *:cnv0:resources obtained via grabit by Sunday before deadline [4/4] *:cnv0:proper error checking and status reporting performed [6/6] *:cnv0:correct variable types and name lengths used [6/6] *:cnv0:proper output formatting per specifications [6/6] *:cnv0:proper selection logic applied to perform comparisions [6/6] *:cnv0:proper iteration logic applied to carry out process [6/6] *:cnv0:runtime verify tests of submission succeed [6/6] *:cnv0:no negative compiler messages for program [6/6] *:cnv0:code is pushed to lab46 repository [6/6] ===Pertaining to the collaborative authoring of project documentation=== * each class member is to participate in the contribution of relevant information and formatting of the documentation * minimal member contributions consist of: * near the class average edits (a value of at least four productive edits) * near the average class content change average (a value of at least 256 bytes (absolute value of data content change)) * near the class total content contribution average (a value of at least 1kiB) * no zero-sum commits: no adding in one commit then later removing in its entirety for the sake of satisfying edit requirements * adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference * content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result: * no contributions, co-efficient is 0.50 * less than minimum contributions is 0.75 * met minimum contribution threshold is 1.00 ===Additionally=== * Solutions not abiding by spirit of project will be subject to a 50% overall deduction * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction