Lab46 Wiki

User Tools

Site Tools

You are here: start » haas » fall2022 » cprog » projects » sof0
haas:fall2022:cprog:projects:sof0

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
haas:fall2022:cprog:projects:sof0 [2021/09/03 14:42] – created - external edit 127.0.0.1haas:fall2022:cprog:projects:sof0 [2022/09/18 13:26] (current) – [RUBRIC] wedge
Line 4: Line 4:
 </WRAP> </WRAP>
  
-======Project: MENTAL MATH - SQUARES OF FIVES (sof0)======+======PROJECT: MENTAL MATH - SQUARES OF FIVE (SOF0)======
  
 +=====OBJECTIVE=====
 +To begin our exploration of programming, starting with an investigation into the various data types available in C, along with their properties, and collaboratively authoring and documenting the project and its specifications.
  
-=====Objective===== +=====GRABIT===== 
-To implement a programmatic solution (ie simulation) of a real life process- the mental math trick of computing the square of any number ending with 5. +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.
- +
-=====Scope===== +
-The allure of using (and learning) a programming language is to be able to effectively use it to solve problems, which in and of themselves are simulations of some process we can do in "the real world". +
- +
-In this case, we will be writing a program which will implement the mental math techniques for computing the square of any one, two-, or three-digit number that ends with 5. +
- +
-=====Background===== +
-Mental Math constitutes an intersection of mental techniques and math- instead of utilizing a purely math-only solution, textual manipulations or simplifications in the computational process may take place enabling an individual to, once having learned the process, solve such problems in their head, and typically without the use of a calculating device. +
- +
-The process in this case is one of numeric manipulation and simple (reduced) multiplication. To wit: +
- +
-====Squaring a value==== +
-Squaring is essentially multiplying a number by itself- +
- +
-  * 5 squared (5<nowiki>^</nowiki>2) is 5*5 or 25 +
-  * 8 squared (8<nowiki>^</nowiki>2) is 8*8 or 64 +
- +
-While not outwardly a difficult procedure, the nature of multiplying multiple digit numbers in your head can quickly result in more steps (and more steps means more time, if doing things the traditional way). +
- +
-Finding a shortcut through this process enables it to remain solidly within the realm of mental math, and makes for a good algorithm to practice implementing on the computer. +
- +
-This particular trick relies on a subset of the squares: those ending with a 5 (a five in the ones place). +
- +
-The implementational scope of this trick will be just values of one-, two-, and three-digits ending with 5: +
- +
-  * 5 +
-  * 15 +
-  * 25 +
-  * 35 +
-  * 45 +
-  * 55 +
-  * 65 +
-  * 75 +
-  * 85 +
-  * 95 +
-  * 105 +
-  * 115 +
-  * 125 +
-  * ... +
-  * 235 +
-  * 245 +
-  * ... +
-  * 485 +
-  * 495 +
-  * 505 +
-  * ... +
-  * 995 +
- +
- +
-====Squaring values ending with 5==== +
-The trick here is two-fold. First, we separate the one's place 5 from the rest of the number (which can be accomplished in our mind's easily enough, but on the computer we must resort to some math). +
- +
-We then take that isolated five and square it; we'll get 25. That is how our result will end (so bam! we now have our tens and ones place already solved) +
- +
-Next, we take the remaining digits of the original value, and multiply it by its increment: +
- +
-  * 1's increment (1+1) is 2, so 1*2 +
-  * 2's increment (2+1) is 3, so 2*3 +
-  * 3's increment (3+1) is 4, so 3*4 +
-  * 4's increment (4+1) is 5, so 4*5 +
-  * ... +
-  * 9's increment (9+1) is 10, so 9*10 +
- +
-We take this result and append the 25 after it. +
- +
-For example: +
- +
-<code> +
-15 * 15 = 1*(1+1) 5*5 +
-        = 1*2     5*5 +
-        = 2       25 +
-        = 225 +
-</code> +
- +
-and: +
- +
-<code> +
-75 * 75 = 7*(7+1) 5*5 +
-        = 7*8     5*5 +
-        = 56      25 +
-        = 5625 +
-</code> +
- +
-For a single digit number like 5, when you take the 5 away, what do you get? **ZERO**. Zero times anything is zero, so the result is 0 25, or 25 (ie this process still works). +
- +
-For three digit numbers like 105, we have 10, and its increment is 11, so 10 x 11 = 110. +
- +
-<code> +
-105 * 105 = 10*(10+1) 5*5 +
-          = 10*11     5*5 +
-          = 110       25 +
-          = 11025 +
-</code> +
-=====Program===== +
-It is your task to write the program that will use the above method to compute the square of the input value ending with a 5 (you are to input the entire number, including the 5 at the end). +
- +
-Your program should: +
-  * prompt the user for the number (input) +
-    * input number as an unsigned short integer +
-  * perform the task (process) +
-    * isolate one's digit mathematically, store in a variable (unsigned short int) +
-    * isolate remaining digits mathematically, store in another variable (unsigned short int) +
-    * perform the algorithm on the two pieces, storing their results in two separate variables (of type unsigned short int) +
-  * display the final value (output) +
-    * display the beginning and ending parts together (but stored in separate variables) +
-    * display the resulting number to STDOUT (right-justified in a space supporting the largest possible value -- see output example below) +
-    * display any supporting text to STDERR (display of source values left-justified in a space supporting 3-digit values -- see output example below). +
-  * because we have not officially learned how to do selection/have the computer react to conditions, please implement with the assumption that the user will ALWAYS input a correct value. Do not worry about having to check for invalid or illegal input values (I will not be checking for such when I evaluate your project). +
- +
-=====Execution=====+
  
 <cli> <cli>
-yourpi:~/src/SEMESTER/cprog/sof0$ ./sof0.armv7l +lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT
-Enter value: 75 +
-75  x 75  =   5625 +
-yourpi:~/src/SEMESTER/cprog/sof0$ +
 </cli> </cli>
  
-The execution of the program is short and simple- obtain the input, do the processing, produce the output, and then terminate.+=====OVERVIEW===== 
 +Your task is to write a program that performs the mental math technique of squaring any 1-, 2-, or 3-digit number that ends in a 5.
  
-Note how the two "75" values are left-justified within a 3-space slot (with the multiplication 'x' and equal sign '=' being padded with a space on either side). This information should all be displayed to STDERR.+Contributing to project documentation is also a core part of this project. If from reading the existing documentation or through your own exploring, you find something lacking, unclear, or outright missing, that is an opportunity to potentially contribute content.
  
-Similarly, here's an example of 105x105:+You want the project documentation to provide you (as if coming in with no awareness of the project) with sufficient information so as to allow you to proceed. Asking questions on the discord is a great way of getting more information that you can use to add content. 
 +=====EDIT===== 
 +You will want to go [[/notes/cprog/fall2022/projects/sof0|here]] to edit and fill in the various sections of the document:
  
-<cli> +  * [[/notes/cprog/fall2022/projects/sof0|https://lab46.g7n.org/notes/cprog/fall2022/projects/sof0]]
-yourpi:~/src/SEMESTER/cprog/sof0$ ./sof0.armv7l +
-Enter value: 105 +
-105 x 105 =  11025 +
-yourpi:~/src/SEMESTER/cprog/sof0$  +
-</cli>+
  
-The 'x' and '=' padding persists, but because we're squaring a 3-digit value vs. a 2-digit value, we occupy the entire allocated space on the screen.+{{page>notes:cprog:fall2022:projects:sof0&nouser&nodate&nomdate}}
  
-If you'd like to verify successful output to STDOUT/STDERR, you can perform the following tests. First, verify that the answer (and ONLY the answer), is being sent to STDOUT -- we do this by eliminating STDERR entirely:+=====SUBMISSION===== 
 +To be successful in this project, the following criteria (or their equivalent) must be met:
  
-<cli> +  * Project must be submit on time, by the deadline. 
-yourpi:~/src/SEMESTER/cprog/sof0$ ./sof0.armv7l 2> /dev/null <<< 105 +    * Late submissions will lose 33%  credit per day, with the submission window closing on the 3rd day following the deadline. 
- 11025 +  * All code must compile cleanly (no warnings or errors) 
-yourpi:~/src/SEMESTER/cprog/sof0$  +    * Compile with the **-Wall** and **--std=gnu18** compiler flags 
-</cli>+    * all  requested functionality  must conform  to stated  requirements (either on  this document or  in a comment banner in  source code files themselves). 
 +  * Executed programs must display in a manner similar to provided output 
 +    * output  formatted,  where applicable,  must match  that of  project requirements 
 +  * Processing must be correct based on input given and output requested 
 +  * Output, if applicable, must be correct based on values input 
 +  * Code must be nicely and consistently indented 
 +  * Code must be consistently written, to strive for readability from having a consistent style throughout 
 +  * Code must be commented 
 +    * Any "to be implemented" comments **MUST** be removed 
 +      * these   "to  be  implemented"   comments,  if  still  present  at evaluation time, will result in points being deducted. 
 +      * Sufficient  comments  explaining  the point  of  provided   logic **MUST** be present 
 +  * No global variables (without instructor approval), no goto statements, no calling of main()! 
 +  * Track/version the source code in your lab46 semester repository 
 +  * Submit  a copy of  your source code to  me using the  **submit** tool (**make submit** on lab46 will do this) by the deadline.
  
-What we are doing here is two-fold: +====Submit Tool Usage==== 
- +Let's  say you  have completed  work  on the  project, and  are ready  to 
-  * We are using command-line I/O redirection to redirect STDERR (which is bound to file descriptor #2) to the system bit-bucket. +submit, you  would do the following  (assuming you have a  program called 
-  * We are "redirecting" STDIN using a **here string**, providing the program's input of **105** right on the command-line at time of execution. +uom0.c):
- +
-Similarly, if we were to eliminate STDOUT entirely (for verifying STDERR output):+
  
 <cli> <cli>
-yourpi:~/src/SEMESTER/cprog/sof0$ ./sof0.armv7l 1> /dev/null +lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit
-Enter value: 75 +
-75  x 75  = yourpi:~/src/SEMESTER/cprog/sof0$ +
 </cli> </cli>
  
-What we are doing here:+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.
  
-  * We are using command-line I/O redirection to redirect STDOUT (which is bound to file descriptor #1) to the system bit-bucket. +=====RUBRIC===== 
- +I'll be evaluating the project based on the following criteria:
-=====Verification===== +
-One of the tests I will perform for output compliance of your code will involve comparing your program's output against a range of input values, to see if they all output in conformance with project specifications. +
- +
-I will make use of a checksum to verify exactness. +
- +
-You will need to run this from your sof0 project directory with a compiled and operational binary by the name of **sof0**. +
- +
-You can check your project by typing in the following at the prompt: +
- +
-<cli> +
-lab46:~/src/SEMESTER/cprog/sof0$ pchk cprog sof0 +
-</cli> +
- +
-If all aligns, you will see this: +
- +
-<cli> +
-================================================== +
-=   CPROG sof0 project output validation tool    = +
-================================================== +
-sof0 checksum is: 822a47fb2a45845500b6c10878045bd5 +
-your checksum is: 822a47fb2a45845500b6c10878045bd5 +
-================================================== +
-    verification: SUCCESS! +
-================================================== +
-</cli> +
- +
-If something is off, your checksum will not match the sof0 checksum, and verification will instead say "**MISMATCH**", like follows (note that a mismatched checksum can be anything, and likely not what is seen in this example): +
- +
-<cli> +
-================================================== +
-=   CPROG sof0 project output validation tool    = +
-================================================== +
-sof0 checksum is: 822a47fb2a45845500b6c10878045bd5 +
-your checksum is: 92af264c86823a61529948caaeac53e0 +
-================================================== +
-    verification: MISMATCH +
-================================================== +
-</cli> +
-=====Questions / Food for Thought===== +
-These are things I'd like you to contemplate, even use as potential material on your weekly journal entry. The more you think about and understand the problem, the better your ability to solve it and other problems. +
- +
-  * Why/how does this trick work for 1-digit numbers? +
-  * Considering our 1-, 2-, and 3-digit domain restriction for this project, how many candidate values are there for input? +
-  * What is the smallest input value? +
-  * What is the largest input value? +
-  * How many input values are there that end in **5**? +
-  * What is the largest square that can be calculated given the project input restrictions? +
-  * How many digits is the largest square? +
-  * How can knowing how many digits the largest square is help you implement your solution? +
- +
-=====Review of Compiling/Executing===== +
-Just to review the compilation/execution process for working with your source code, if we had a file, **hello.c**, that we wished to compile to a binary called **hello**, we'd first want to compile the code, as follows. +
- +
-If compiling on lab46: +
- +
-<cli> +
-lab46:~/src/SEMESTER/cprog/PROJECT$ gcc -Wall --std=gnu99 -funsigned-char -o PROJECT.x86_64 PROJECT.c +
-lab46:~/src/SEMESTER/cprog/PROJECT$  +
-</cli> +
- +
-If compiling on your pi system: +
- +
-<cli> +
-yourpi:~/src/SEMESTER/cprog/PROJECT$ gcc -Wall --std=gnu99 -funsigned-char -o PROJECT.armv7l PROJECT.c +
-yourpi:~/src/SEMESTER/cprog/PROJECT$  +
-</cli> +
- +
-Assuming there are no syntax errors or warnings, and everything compiled correctly, you should just get your prompt back. In the event of problems, the compiler will be sure to tell you about them. +
- +
-Conceptually, the arrangement is as follows:+
  
 <code> <code>
-gcc -Wall --std=gnu99 -funsigned-char -o BINARY_FILE SOURCE_FILE+39:sof0:final tally of results (39/39) 
 +*:sof0:used grabit to obtain project by the Sunday prior to duedate [6/6] 
 +*:sof0:clean compile, no compiler messages [7/7] 
 +*:sof0:program conforms to project specifications [20/20] 
 +*:sof0:code tracked in lab46 semester repo [6/6]
 </code> </code>
  
-The BINARY_FILE comes **immediately after** the **-o**, **NOT** the SOURCE_FILE (the source file must never **immediately** follow a **-o**). It can precede, and such is perfectly valid (especially if you feel that way more intuitive).+===Pertaining to the collaborative authoring of project documentation===
  
-The **-Wall** (treat all warnings as errors, increase general verbosity about warnings) and **<nowiki>--std=gnu99</nowiki>** (switch compiler to use the **C99** standard of the C language, with GNU extensions) are options given to the compiler. The **<nowiki>-funsigned-char</nowiki>** flag forces "char" types lacking a signed/unsigned qualifier to default to unsigned.+  * 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 content contribution average (a value of at least 1kiB) 
 +      * 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
  
-To execute your binary, we need to specify a path to it, so we use **./**, which basically references the current directory. +===Additionally===
- +
-On lab46: +
- +
-<cli> +
-lab46:~/src/SEMESTER/cprog/PROJECT$ ./PROJECT.x86_64 +
-</cli> +
- +
-On your pi system: +
- +
-<cli> +
-yourpi:~/src/SEMESTER/cprog/PROJECT$ ./PROJECT.armv7l +
-</cli> +
- +
-=====Submission===== +
-To successfully complete this project, the following criteria must be met: +
- +
-  * Code must compile cleanly (no warnings or errors) +
-    * Use the **-Wall** and **<nowiki>--std=gnu99</nowiki>** flags when compiling. +
-  * Executed program must display a total of 2 lines, one for input, one for output. +
-    * The computed number must be output to STDOUT +
-    * Any supporting output must be output to STDERR +
-    * Output is formatted in the manner in the sample above +
-  * Output must be correct, and match the form given in the sample output above. +
-  * Code must be nicely and consistently indented +
-  * Code must implement solution using the mental math technique described above +
-  * Code must be commented +
-    * have a properly filled-out comment banner at the top +
-    * have at least 20% of your program consist of **<nowiki>//</nowiki>**-style descriptive comments +
-  * Output Formatting (including spacing) of program must conform to the provided output (see above). +
-  * Track/version the source code in a repository +
-  * 33% late penalty per day after deadline +
-  * Program is submit in a C source file called **sof0.c** and compiles without warning, note, nor error with gcc on lab46. +
-  * Submit a copy of your source code to me using the **submit** tool. +
- +
-To submit this program to me using the **submit** tool, run the following command at your lab46 prompt: +
- +
-<cli> +
-lab46:~/src/SEMESTER/cprog/sof0$ make submit +
-</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. +
- +
-I'll be looking for the following: +
- +
-<code> +
-39:sof0:final tally of results (39/39) +
-*:sof0:obtained via grabit by Sunday before deadline [3/3] +
-*:sof0:program compiles successfully, no errors [3/3] +
-*:sof0:program compiles with no warnings [3/3] +
-*:sof0:program performs stated task/algorithm [3/3] +
-*:sof0:program output conforms to formatting expectations [3/3] +
-*:sof0:proper error checking and status reporting performed [3/3] +
-*:sof0:code implements solution using relevant concepts [3/3] +
-*:sof0:code updates committed/pushed to lab46 semester repo [3/3] +
-*:sof0:code uses correct variable types and name lengths [3/3] +
-*:sof0:project is submitted with relevant and complete source [3/3] +
-*:sof0:project is submitted on lab46 using 'make submit' [3/3] +
-*:sof0:project is submitted with pi and lab46 binaries [3/3] +
-*:sof0:runtime tests of submitted program succeed [3/3] +
-</code>+
  
-Additionally: +  * Solutions not abiding  by spirit of project will be  subject to a 50% overall deduction 
-  * Solutions not abiding by **SPIRIT** of project will be subject to a 25% overall deduction +  * Solutions  not  utilizing descriptive  why and  how comments  will be subject to a 25% 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 utilizing **INDENTATION** to promote scope and clarity 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
-  * Solutions lacking **ORGANIZATION** and are not easy to read (within 90 char width) are subject to a 25% overall deduction+
haas/fall2022/cprog/projects/sof0.1630680135.txt.gz · Last modified: 2021/09/03 14:42 by 127.0.0.1

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki