This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:spring2017:cprog:projects:mbe0 [2017/02/06 12:24] – [Prerequisites/Corequisites] wedge | haas:spring2017:cprog:projects:mbe0 [2017/02/15 15:42] (current) – [Total output comparison] wedge | ||
---|---|---|---|
Line 8: | Line 8: | ||
======Project: | ======Project: | ||
+ | =====Errata===== | ||
+ | |||
+ | * Added verification section to facilitate project output specification compliance (20170207) | ||
+ | * Added automatic verification subsection to verification section (20170208) | ||
=====Objective===== | =====Objective===== | ||
- | To implement a programmatic solution (ie simulation) of a real life process- the mental math trick of multiplying any one-, two-, or three-digit number by eleven. | + | To implement a programmatic solution (ie simulation) of a real life process- the mental math trick of multiplying any two- or three-digit number by eleven. |
=====Prerequisites/ | =====Prerequisites/ | ||
Line 22: | Line 26: | ||
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" | 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 multiplying any one-, two-, or three-digit number by eleven. | + | In this case, we will be writing a program which will implement the mental math techniques for multiplying any two- or three-digit number by eleven. |
=====Background===== | =====Background===== | ||
Line 29: | Line 33: | ||
The process in this case is one of pattern matching, number manipulation, | The process in this case is one of pattern matching, number manipulation, | ||
- | ====Multiplying any single digit number by 11==== | ||
- | This may be a pattern of which you are already aware- to multiply any single-digit number (base 10) by eleven, you simply duplicate the digit twice. | ||
- | |||
- | In the case of 1 x 11, we get: 11 | ||
- | |||
- | For 2 x 11, we see: 22 | ||
- | |||
- | For 3 x 11, we have: 33 | ||
- | |||
- | and this trick works all the way through 9 x 11, yielding: 99 | ||
====Multiplying any double digit number by 11==== | ====Multiplying any double digit number by 11==== | ||
Line 172: | Line 166: | ||
=====Program===== | =====Program===== | ||
- | It is your task to write the program that will use the above method to compute the requested | + | It is your task to write the program that will use the above method to compute the requested two- or three-digit value against a multiplicand of 11 (without using any multiplication to obtain your result). |
Your program should: | Your program should: | ||
* obtain its input from STDIN. | * obtain its input from STDIN. | ||
- | * input should be in the form of a single integer value | + | * input should be in the form of a single |
- | * determine from the input if it is a one-, two-, or three-digit number | + | * no string processing! |
- | * perform the correct | + | * declare and utilize these 9 **unsigned char** variables, named and described as follows: |
- | * propagate any carries | + | * **sum10000** (to store the 10000s place sum digit) |
- | * output the final value | + | * **carry1000** (to store the 1000s place carry digit) |
- | * you can display each digit individually, or combine them into one variable and display that (whichever you prefer) | + | * **sum1000** (to store the 1000s place sum digit) |
+ | * **carry100** (to store the 100s place carry digit) | ||
+ | * **sum100** (to store the 100s place sum digit) | ||
+ | * **carry10** (to store the 10s place carry digit) | ||
+ | * **sum10** (to store the 10s place sum digit) | ||
+ | * **carry1** (to store the 1s place carry digit) | ||
+ | * **sum1** (to store the 1s place sum digit) | ||
+ | * perform the described | ||
+ | * all output except for final value goes to STDERR | ||
+ | * output the final value to STDOUT | ||
+ | * display each digit individually (all packed together) | ||
+ | * no loops, repetition, recursion, nor goto statements | ||
=====Execution===== | =====Execution===== | ||
Several operating behaviors are shown as examples. | Several operating behaviors are shown as examples. | ||
- | A two digit value: | + | A two digit value with no carries: |
<cli> | <cli> | ||
- | lab46: | + | lab46: |
Enter value: 32 | Enter value: 32 | ||
- | 32 x 11 = 352 | + | 32 x 11 = |
+ | | ||
+ | = 352 | ||
lab46: | lab46: | ||
</ | </ | ||
- | Next, a one digit value: | + | A two digit value with carries: |
<cli> | <cli> | ||
- | lab46: | + | lab46: |
- | Enter value: | + | Enter value: |
- | 7 x 11 = 77 | + | 86 x 11 = 8 |
+ | | ||
+ | | ||
+ | | ||
+ | = 946 | ||
lab46: | lab46: | ||
</ | </ | ||
- | Finally, | + | A three digit value with no carries: |
<cli> | <cli> | ||
- | lab46: | + | lab46: |
+ | Enter value: 123 | ||
+ | 123 x 11 = | ||
+ | | ||
+ | = 1353 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | A three digit value with carries: | ||
+ | |||
+ | < | ||
+ | lab46: | ||
Enter value: 567 | Enter value: 567 | ||
- | 567 x 11 = 6237 | + | 567 x 11 = |
+ | | ||
+ | | ||
+ | | ||
+ | = 6237 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | The maximum input value (three digit value with carries; note how it fills the spacing): | ||
+ | |||
+ | < | ||
+ | lab46: | ||
+ | Enter value: 999 | ||
+ | 999 x 11 = | ||
+ | | ||
+ | | ||
+ | | ||
+ | = (0+1) | ||
+ | | ||
+ | = 10989 | ||
lab46: | lab46: | ||
</ | </ | ||
The execution of the program is short and simple- obtain the input, do the processing, produce the output, and then terminate. | The execution of the program is short and simple- obtain the input, do the processing, produce the output, and then terminate. | ||
+ | |||
+ | ====Output Specification==== | ||
+ | As you can see, there' | ||
+ | |||
+ | <cli> | ||
+ | Enter value: 967 | ||
+ | 967 x 11 = | ||
+ | | ||
+ | | ||
+ | | ||
+ | = (0+1) | ||
+ | | ||
+ | = 10637 | ||
+ | </ | ||
+ | |||
+ | With the exception of the final (packed together) 10637, everything is displayed to STDERR (that 10637 is the only thing to display to STDOUT). | ||
+ | |||
+ | Some important things of note: | ||
+ | * The input value should be //right justified// in a 3 space allocated location to just before the " x 11". | ||
+ | * The equal sign has a space padding it on each side: " = " | ||
+ | * The output is calibrated for working with 5 digits. If there are no digits in those further left places, blanks must be displayed instead (in the 10637 example above, the first four lines are only dealing with 4 digits, until a carry propagates over to a 5th digit). | ||
+ | * Each digit of output needs to be calibrated to potentially display an addition operation, wrapped in parenthesis (as you see in the above example: (9+1) | ||
+ | * if only a single value is being displayed, it must appear where the ' | ||
+ | * if the number to display is a 2-digit number (10-18), its one's place needs to line up with the ' | ||
+ | * each digit space has a single space separating it from the next digit space. | ||
+ | * The final digit column (which should never have a carry) has a newline immediately following it (no trailing spaces). | ||
+ | * At the beginning, the leftmost and rightmost digits are displayed, with the additions visualized on the inner digits, according to the length. | ||
+ | * If there are any additions, the next line needs to show the result of those additions. | ||
+ | * Following any result, carries should be checked for. If any carries are generated, a new line visualizing the additions must be displayed, then another line with the result. This process needs to propagate as many times as needed (thankfully, | ||
+ | * Obviously, if the problem resolves sooner, it does, without needing to display those extra lines. Study the other execution examples, they demonstrate this. | ||
+ | |||
+ | You will probably find some application for selection statements, gaining further experience with them and likely deploying them with more sophisticated relational conditions (even compound ones). | ||
+ | |||
+ | Output formatting is still an important aspect to keep in mind. The computer needs to be told exactly what to do, and our default habits would likely be to do " | ||
+ | |||
+ | Another aspect of the output requirements is that they will force a focus on the individual steps of processing using this algorithm. This should help add exposure to developing good habits of ceasing to automatically read between the lines, and to identify and focus on the discrete steps needed to accomplish the task at hand. | ||
+ | |||
+ | =====Verification===== | ||
+ | Following are some procedures you can follow to verify if your program' | ||
+ | |||
+ | ====STDOUT verification of answer==== | ||
+ | As the final answer (and ONLY the answer) is to be output to STDOUT, your can run the following to check to see if this is the case with your program: | ||
+ | |||
+ | ===3-digit result=== | ||
+ | <cli> | ||
+ | lab46: | ||
+ | 704 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ===4-digit result=== | ||
+ | <cli> | ||
+ | lab46: | ||
+ | 5632 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ===5-digit result=== | ||
+ | <cli> | ||
+ | lab46: | ||
+ | 10197 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====Total output comparison==== | ||
+ | If you'd like to check if the entirety of your output is correct (especially in relation to spacing), you can do the following. | ||
+ | |||
+ | I have saved sample (correct) outputs on the system that you can check against. The following commands will let you do so: | ||
+ | |||
+ | ===First, save your output to a file=== | ||
+ | |||
+ | I have saved program outputs for the following inputs: | ||
+ | * 37 | ||
+ | * 73 | ||
+ | * 128 | ||
+ | * 480 | ||
+ | * 907 | ||
+ | * 933 | ||
+ | |||
+ | If you run your program with one of these same inputs, you can compare your results for correctness. | ||
+ | |||
+ | In the below example, I do this for an input value of 37: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | What we have done is fed in the input via a here string (form of STDIN redirect), and then output both STDERR and STDOUT into a common file (appending STDOUT, after the STDERR output). | ||
+ | |||
+ | You should now have a file called **output.37** in your current directory. | ||
+ | |||
+ | ===Next, check it against mine=== | ||
+ | I have these files (by the same names), saved in the CPROG Public Directory (under the **mbe0** directory). | ||
+ | |||
+ | By using the **diff** command, you can see differences, | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | If you see output, that means there are differences, | ||
+ | |||
+ | You can repeat this for the other data files (output.73 for an input of 73, etc.) | ||
+ | |||
+ | ===Isolate just the STDOUT or the STDERR=== | ||
+ | Additionally, | ||
+ | |||
+ | To do this, you can do the following. | ||
+ | |||
+ | To isolate STDOUT and STDERR into separate files, you can do the following: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | You can then compare those particular collections of information against my copies (located in the **mbe0** subdirectory of the CPROG Public Directory, by the same file names). | ||
+ | ====automated verification==== | ||
+ | I have rigged up **pchk** to work for this project; it will check for differences and compare MD5sum hashes for stderr, stdout, and total (combined) output. | ||
+ | |||
+ | Once you have everything complete, this is a good final check to do to ensure everything is in order. | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | =================================================== | ||
+ | = mbe0 output validation check = | ||
+ | =================================================== | ||
+ | stderr diff: MATCH stderr md5sum: MATCH | ||
+ | [ 37] stdout diff: MATCH stdout md5sum: MATCH | ||
+ | output diff: MATCH output md5sum: MATCH | ||
+ | |||
+ | stderr diff: MATCH stderr md5sum: MATCH | ||
+ | [ 73] stdout diff: MATCH stdout md5sum: MATCH | ||
+ | output diff: MATCH output md5sum: MATCH | ||
+ | |||
+ | stderr diff: MATCH stderr md5sum: MATCH | ||
+ | [128] stdout diff: MATCH stdout md5sum: MATCH | ||
+ | output diff: MATCH output md5sum: MATCH | ||
+ | |||
+ | stderr diff: MATCH stderr md5sum: MATCH | ||
+ | [480] stdout diff: MATCH stdout md5sum: MATCH | ||
+ | output diff: MATCH output md5sum: MATCH | ||
+ | |||
+ | stderr diff: MATCH stderr md5sum: MATCH | ||
+ | [907] stdout diff: MATCH stdout md5sum: MATCH | ||
+ | output diff: MATCH output md5sum: MATCH | ||
+ | |||
+ | stderr diff: MATCH stderr md5sum: MATCH | ||
+ | [933] stdout diff: MATCH stdout md5sum: MATCH | ||
+ | output diff: MATCH output md5sum: MATCH | ||
+ | =================================================== | ||
+ | = | ||
+ | =================================================== | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | Since your project submission will be evaluated in part by compliance to output specifications, | ||
=====Reflection===== | =====Reflection===== | ||
- | Be sure to provide any commentary on your opus regarding realizations had and discoveries made during your pursuit of this project. | + | Be sure to provide any commentary on your journal |
* Does this process work for four digit numbers? | * Does this process work for four digit numbers? | ||
Line 225: | Line 425: | ||
* Code must compile cleanly (no warnings or errors) | * Code must compile cleanly (no warnings or errors) | ||
+ | * Again, I will be compiling as follows: gcc -Wall -o mbe0 mbe0.c | ||
+ | * Submit the program in a file called **mbe0.c** | ||
* Output must be correct, and match the form given in the sample output above. | * Output must be correct, and match the form given in the sample output above. | ||
* Code must be nicely and consistently indented (you may use the **indent** tool) | * Code must be nicely and consistently indented (you may use the **indent** tool) | ||
Line 240: | Line 442: | ||
<cli> | <cli> | ||
- | $ submit cprog mbe0 multby11.c | + | $ submit cprog mbe0 mbe0.c |
Submitting cprog project " | Submitting cprog project " | ||
- | -> multby11.c(OK) | + | -> mbe0.c(OK) |
SUCCESSFULLY SUBMITTED | SUCCESSFULLY SUBMITTED | ||
Line 248: | Line 450: | ||
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. | 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. | ||
+ | |||
+ | What I'll be looking for: | ||
+ | |||
+ | < | ||
+ | 52: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *:mbe0:sum variables declared and used appropriately in processing [4/4] | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *:mbe0:no negative compiler messages for code [4/4] | ||
+ | *:mbe0:code is pushed to lab46 repository [4/4] | ||
+ | </ |