<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS1320 C/C++ Programming</fs></WRAP>
</WRAP>

======Project: MENTAL MATH - MULTIPLY BY 11 (mbe1)======

=====Objective=====
To implement a programmatic solution (ie simulation) of a real life process- the mental math trick of multiplying any two- through eight-digit number by eleven.

=====Prerequisites/Corequisites=====
In addition to the new skills required on previous projects, to successfully accomplish/perform this project, the listed resources/experiences need to be consulted/achieved:

  * can perform this multiply by 11 trick in your head/by hand (if you can't do it on your own, you have no business trying to tell the computer how to do it)
  * understand the pattern/process to doing it for any length number (2-digit through 8-digit)
  * ability to deploy loops to simplify your process
  * ability to use arrays to facilitate the storage of your processed values
=====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 multiplying any one- through eight-digit number by eleven.

=====Background=====
In the **mbe0** project, we commenced our exploration of this multiply by 11 mental math trick. Using it as a playground for better understanding the newly introduced conditional (ie **if**) statement, we explored the mental math solving of "multiplying" any 2- or 3-digit number by 11 (multiplying without actually using multiplication-- instead relying on pivoting and a series of rippling additions).

We explored single digit additions, a nostalgic throwback to 2nd/3rd/4th grade math, where we learned how any addition results in a one-digit sum as well as a one-digit carry. The sum occupies a place value in our answer, where the carry is applied to the addition of the next highest place value.

It is hoped that by accomplishing **mbe0**, you both got in some good practice with **if** statements, utilizing math to aid you in per-digit numeric manipulations, and perhaps even seeing your code start to get a little lengthy and noticeably repetitive (can you see similarities between the process for solving for 2-digits vs. that of 3-digits?) Wouldn't it have been nice if we could somehow have simplified that-- only write the process out once, and yet allow the computer to use it as appropriate to solve our task at hand? This week we explore two new concepts-- each individually important on their own, but often used together to supercharge our ability to solve problems.

I am referring to **loops** and **arrays**

====loops====
A loop is basically instructing the computer to repeat a section, or block, or code a given amount of times (it can be based on a fixed value-- repeat this 4 times, or be based on a conditional value-- keep repeating as long as (or while) this value is not 4).

Loops enable us to simplify our code-- allowing us to write a one-size-fits all algorithm (provided the algorithm itself can appropriately scale!), where the computer merely repeats the instructions we gave. We only have to write them once, but the computer can do that task any number of times.

Loops can be initially difficult to comprehend because unlike other programmatic actions, they are not single-state in nature-- loops are multi-state. What this means is that in order to correctly "see" or visualize a loop, you must analyze what is going on with EACH iteration, watching the values/algorithm/process slowly march from its initial state to its resultant state. Think of it as climbing a set of stairs... yes, we can describe that action succinctly as "climbing a set of stairs", but there are multiple "steps" (heh, heh) involved: we place our foot, adjust our balance-- left foot, right foot, from one step, to the next, to the next, allowing us to progress from the bottom step to the top step... that process of scaling a stairway is the same as iterating through a loop.

With that said, it is important to be able to focus on the process of the individual steps being taken. What is involved in taking a step? What constitutes a basic unit of stairway traversal? If that unit can be easily repeated for the next and the next (and in fact, the rest of the) steps, we've described the core process of the loop, or what will be iterated a given number of times.

In C and C-derived languages, we typically have 3 loops:

  * for loop (automatic counter loop, stepping loop) - when we know exactly how many times we wish something to run; we know where we want to start, where we want to end, and exactly how to progress from start to end (step value)
  * while loop (top-driven conditional loop) - when we want to repeat a process, but the exact number of iterations is either not known, or not important. While loops can run 0 or more times.
  * do-while loop (bottom-driven conditional loop) - similar to the while loop, only we do the check for loop termination at the bottom of the loop, meaning it runs 1 or more times (a do-while loop is guaranteed to run at least once).

===for loops===
A for loop is the most syntactically unique of the loops, so care must be taken to use the proper syntax.

With any loop, we need (at least one) looping variable, which the loop will use to analyze whether or not we've met our looping destination, or to perform another iteration.

A for loop typically also has a defined starting point, a "keep-looping-while" condition, and a stepping equation.

Here's a sample for loop, in C, which will display the squares of each number, starting at 0, and stepping one at a time, for 8 total iterations:

<code c>
int i = 0;

for (i = 0; i < 8; i++)
{
    fprintf(stdout, "loop #%d ... %d\n", (i+1), (i*i));
}
</code>

The output of this code, with the help of our loop should be:

<cli>
loop #1 ... 0
loop #2 ... 1
loop #3 ... 4
loop #4 ... 9
loop #5 ... 16
loop #6 ... 25
loop #7 ... 36
loop #8 ... 49
</cli>

Note how we can use our looping variable (**i**) within mathematical expressions to drive a process along... loops can be of enormous help in this way.

And again, we shouldn't look at this as one step-- we need to see there are 8 discrete, distinct steps happening here (when i is 0, when i is 1, when i is 2, ... up until i is 7).

The loop exits once **i** reaches a value of 8, because our loop determinant condition states as long as **i** is **less than** **8**, continue to loop. Once **i** becomes **8**, our looping condition has been satisfied, and the loop will no longer iterate.

The stepping (that third) field is a mathematical expression indicating how we wish for **i** to progress from its starting state (of being equal to 0) to satisfying the loop's iterating condition (no longer being less than 8).

**i++** is a shortcut we can use in C; the longhand (and likely more familiar) equivalent is: **i = i + 1**

===while loops===
A while loop isn't as specific about starting and stepping values, really only caring about what condition needs to be met in order to exit the loop (keep looping while this condition is true).

In actuality, anything we use a for loop for can be expressed as a while loop-- we merely have to ensure we provide the necessary loop variables and progressions within the loop.

That same loop above, expressed as a while loop, could look like:

<code c>
int i = 0;

while (i < 8)
{
    fprintf(stdout, "loop #%d ... %d\n", (i+1), (i*i));
    i = i + 1;   // I could have used "i++;" here
}
</code>

The output of this code should be identical, even though we used a different loop to accomplish the task (try them both out and confirm!)

While loops, like for loops, will run 0 or more times; if the conditions enabling the loop to occur are not initially met, they will not run... if met, they will continue to iterate until their looping conditions are met.

It is possible to introduce a certain kind of **logical error** into your programs using loops-- what is known as an "infinite loop"; this is basically where you erroneously provide incorrect conditions to the particular loop used, allowing it to start running, but never arriving at its conclusion, thereby iterative forever.

Another common **logical error** that loops will allow us to encounter will be the "off by one" error-- where the conditions we pose to the loop are incorrect, and the loop runs one more or one less time than we had planned. Again, proper debugging of our code will resolve this situation.

===do-while loops===
The third commonly recognized looping structure in C, the do-while loop is identical to the while (and therefore the for) loop, only it differs in where it checks the looping condition: where **for** and **while** are "top-driven" loops (ie the test for loop continuance occurs at the top of the loop), the **do-while** is a "bottom-driven" loop (ie the test for loop continuance occurs at the bottom of the loop).

The placement of this test determines the minimal number of times a loop can run.

In the case of the for/while loops, because the test is at the top- if the looping conditions are not met, the loop may not run at all. It is for this reason why these loops can run "0 or more times"

For the do-while loop, because the test occurs at the bottom, the body of the loop (one full iteration) is run before the test is encountered. So even if the conditions for looping are not met, a do-while will run "1 or more times".

That may seem like a minor, and possibly annoying, difference, but in nuanced algorithm design, such distinctions can drastically change the layout of your code, potentially being the difference between beautifully elegant-looking solutions and slightly more hackish. They can BOTH be used to solve the same problems, it is merely the nature of how we choose express the solution that should make one more preferable over the other in any given moment.

I encourage you to intentionally try your hand at converting your loops between for/while/do-while in your programs (regardless of how ugly it may make your code), so you can get more familiar with how to structure your solutions and express them in a given type of loop. You will find you tend to think in a certain way (from experience, we seem to get in the habit of thinking "top-driven", and as we're unsure, we tend to exert far more of a need to control the situation, so we tend to want to use **for** loops for everything-- but practicing the others will free your mind to craft more elegant and efficient solutions; but only if you take the time to play and explore these possibilities).

So, expressing that same program in the form of a do-while loop (note the changes from the while):

<code c>
int i = 0;

do {
    fprintf(stdout, "loop #%d ... %d\n", (i+1), (i*i));
    i = i + 1;  // again, we could just as easily use "i++;" here
} while(i < 8);
</code>

In this case, the 0 or more vs. 1 or more minimal iterations wasn't important; the difference is purely syntactical.

With the do-while loop, we start the loop with a **do** statement (feel free to put the opening brace on the next line as we have all along-- I'm also demonstrating another style of brace placement).

Also, the do-while is the only one of our loops which NEEDS a terminating semi-colon (**;**).. please take note of this.

====arrays====
The other important component of our **mbe1** project will involve the effective use of arrays to further aid us in having an efficient (and very importantly: scalable) solution to our problem.

An array is basically just a collection of variables. Where before we'd declare a separate variable for each number we'd wish to store, an array lets us have but one variable name, but multiple storage location (like PO Boxes-- they're all located at the same "place", the post office, but there are multiple boxes for storing individual values). Addressing/location of information can be greatly simplified through the use of arrays.

An array is what is known as a **homogeneous** composite data type. It technically is a modifier (or adjective, if you will) of any valid variable data type. We basically use it to say "I'll take X of these", and slap one name on all of them.

**homogeneous** means all of the same, indicating it can ONLY contain variables of the exact same type (such as only **int**egers, only **short int**egers, only **float**s, only **char**s, etc.)... composite indicates "made up of various parts or elements", or that it is a "container"... it is like a pack of Necco wafers... when you think about it, a pack of Necco wafers ONLY contains necco wafers. You don't see a necco wafer, a pez, an M&M, etc. you ONLY see Necco wafers in a pack of Necco wafers... therefore, a pack of Necco wafers is the same as our array being described (in concept).

An array has a few other requirements:

  * its size, once declared, remains constant (you cannot say you'd like a 4 element array and then later ask to double or halve it--- there is no such thing as "dynamic" arrays or array resizing... even languages that claim to have it, they are lying to you (they are declaring a new array in the background to your altered specifications, copying over all the values, and then presenting that copy as your array)).
  * arrays are located by their name (just as any variable is), along with an address/index/offset (which mailbox, or position of necco wafer in the pack).
  * arrays start at an offset of 0.
  * arrays can be expressed as a pointer (I tend to treat them as pointers), and there's this "bracket notation" we commonly see which is actually trying to hide the pointery truth from you.
  * C cannot perform global operations on arrays-- you must transact on an array one element at a time (this is the case with all languages, although some will cheat and do the work behind-the-scenes, making you think it is possible, when really they are casting illusions).

===Declaring a 4 element integer array===
Let us see our array in action:

<code c>
int numbers[4];
</code>

This code will declare a new variable, of type **int**, called **numbers**... the brackets indicate we are allocating **four** consecutive **int**-sized units that will be associated with this variable called **numbers**... that is, **numbers** is a post office with 4 mailboxes, addressed 0, 1, 2, 3 (0-3 is 4 distinct values).

To access the first box, we access the **0** offset; the second box is right next to the first, at offset **1** (it is one int away from the first one). Similar with the third and fourth.

To place a **17** in the first (position **0**) element of our **numbers** array, we'd say the following:

<code c>
numbers[0] = 17;
</code>

To place a **36** in the third (position **2**) element of our **numbers** array, we'd say:

<code c>
numbers[2] = 36;
</code>

===Using variables as our array index position===
Because the array index is a number, and things like **int**s are numbers, we can also specify the array location via a variable. To wit, we will assign a 52 to the fourth array element, but do so via an **index** variable we set up:

<code c>
int index = 3;
numbers[index] = 52;
</code>

Because **index** contains a 3, we're telling the computer we wish to put a 52 in the array element indicated in the **index** variable (the fourth element).

===Using variables for array contents===
As well, because we are putting values in our array elements that conform to particular data types, we can use variables there as well (in this case, put a 96 into the second array element-- using variables to store both the index and the value):

<code c>
int value = 96;
int index = 1;

numbers[index] = value;
</code>

Hopefully these examples have proved useful with respect to basic concepts and syntactic usage of arrays.

We now explore the productive collaboration of arrays and loops:

====Using loops and arrays together for universal harmony====

To really make the most out of arrays in scaling our algorithms, using them in conjunction with loops gives us the most bang for our buck. The advantage of arrays+loops is that with the ONE consistent variable name, representing many NUMERICALLY-identifiable elements, we can work with ranges of data sets without the need to make tons of exceptions for each possible use case (worst case we just make an array of the maximum expected size, and only use what we need).

===42 everywhere===

To illustrate, here we will declare an 11 element array (called **data**), and fill each element with the value 42 using a for loop:

<code c>
int data[11], position = 0;

for(position = 0; position < 11; position=position+1) // see, using long form, could have done "position++"
{
    data[position] = 42;
}
</code>

===Display array contents===
What if we wanted to print the contents of the array? Once again, we use a loop, and print out each value, one at a time.

Important considerations:
  * again, with C, being true to how the computer actually works, we can only access the array one element at a time
  * because we know array indices start at 0, we have a known starting point
  * because we know how big our array is (11 elements, from previous example), we know how many elements to go for
  * each element is located one after the other-- 0 is followed by 1 is followed by 2 etc.

... therefore, we have all the ingredients for a **for** loop:

<code c>
for (position = 0; position < 11; position++)
{
    fprintf(stdout, "%d ", data[position]);
}
fprintf(stdout, "\n");  // what important role does this line play?
</code>

This should result in the following program output:

<cli>
42 42 42 42 42 42 42 42 42 42 42 
</cli>

===Backwards?===
What if we wanted to display the contents of our array in reverse (from position 10 to position 9, to 8, down to 0)?

We'd still want to use a loop, but look at how we structure it:

<code c>
for (position = 10; position >= 0; position--)
{
    fprintf(stdout, "%d ", data[position]);
}
fprintf(stdout, "\n");  // what important role does this line play?
</code>

Notice how the loop-terminating relational statements differ (comparing the two-- for forward and backward, does it make sense?), and also how we progress between individual elements (in one we are incrementing, in this recent one we are decrementing).

That should make sense before you try to proceed.

===Thinking with arrays===
Using arrays in your algorithms represents a potential barrier you have to overcome. Up until this point, we've been getting used to labelling all our variables with unique, individual names.

Now, with arrays, we have one common name, distinguishable by its element offset. That has been known to cause some conceptual problems due to the mildly abstract nature it creates. It would certainly not hurt to draw some pictures and manually work through some examples, step-by-step... it may be confusing at first, but the more you play with it, ask questions, play, read, etc., the sooner things will start to click.

As some of you have started to realize with **mbe0**, the actual core work of the project wasn't actually that hard, once you saw through the illusion of complexity we had placed in front of it. By using arrays, we can make our solutions even easier (and code even simpler)... but, we will initially have to eliminate self-imposed mental obstacles making the problem appear significantly more difficult than it actually is.


====Multiplying a number (of varying digits) by 11====
In **mbe0**, we specifically looked at 2 usage cases for our mental math problem: 2- and 3-digit numbers. I limited it to those because, lacking arrays and loops for that project, the code would have gotten impossibly long and complex, plus: I wanted you to focus on the basics of variable usage and if-statements.

Now that we have those down, we can now apply arrays and loops to optimize and enhance a solution, and to allow it to scale to a wider range of possibilities (why limit ourselves to just 2- and 3-digit values? Once we see the pattern, we can apply this to 4-, 5-, 6-digit numbers and beyond).

===3-digits (review)===
Again, to review, let's look at a 3-digit example. 123 x 11:

<cli>
     123 x 11 =                                       1   (1+2) (2+3)   3
              =                                       1     3     5     3
              = 1353
</cli>

And digit-based additions that generate a carry are similarly propagated.

567 x 11:

<cli>
     567 x 11 =                                       5   (5+6) (6+7)   7
              =                                       5    11    13     7
              =                                     (5+1) (1+1)   3     7
              =                                       6     2     3     7
              = 6237
</cli>

Some things of note:

  * We know the last digit (1s place) of 567 x 11 right off the bat: 7
  * The second digit (10s place) is the sum of 6 and 7 (6+7) which is 13 (sum of 3, carry of 1), so: 3
  * The third digit (100s place) is the sum of 5 and 6 plus any carry from the 10s place (which is 1), so (5+6+1) which is 12 (sum of 2, carry of 1), so: 2
  * The fourth digit (1000s place) is the original first value (5 of the 567) plus any carry from the 100s place (which there is, a 1), so (5+1) which yields a sum of 6, carry of 0.

A dual benefit of this project is that in addition to extending your programming experience / understanding of C, you could develop this as a mental ability (that is where it originated), and you could then use it as a means of checking your work.

===4-digits===
Now let us process a 4-digit example (look for similarities to the 3-digit process, specifically how this is merely an expansion, or an additional step-- due to the additional digit):

4567 x 11:

<cli>
    4567 x 11 =                                 4   (4+5) (5+6) (6+7)   7
              =                                 4     9    11    13     7
              =                                 4   (9+1) (1+1)   3     7
              =                                 4    10     2     3     7
              =                               (4+1)   0     2     3     7
              =                                 5     0     2     3     7
              = 50237
</cli>

Can you see how "the same" this process for 4-digit numbers is when comparing to the process for 3-digit numbers? And how the same comparison can be made for 2-digit, and 5-digit, 6-digit, etc.? Please take some time, working through some examples (by hand) to identify and notice the pattern, or essence, of this process. You need to see how it doesn't matter in the long run how many digits- because you're doing the same thing (just a different number of times).

That "different number of times" will be based on the length of the number... could that be used to help us?

=====Program=====
It is your task to write an optimized version of your multiply by eleven program that will use arrays and loops to enable you to enhance and expand the functional capabilities of your program. No longer will you be limited by 2-, or 3-digit numbers, but you will be able to input up to (and including!) 8-digit numbers and have your program successfully determine the result (and 8 is merely an arbitrary value I picked, you should easily be able to expand it to even more and experience no change in functionality) -- actually, our 8-digit limit is considering a data type limitation... the maximum size of an int: **signed int**s can have a maximum value of 2.4 billion, so unless we change to a different data type (or different method of inputting the source number), this will be our limitation.

Your program should:
  * obtain its input from STDIN.
    * input should be in the form of a single unsigned integer value
  * take this input, and split it up into individual digits, stored in an unsigned char **sum** array.
    * you may want to put the one's place in the right-most, or last, array position.
    * hint: you will want to make your arrays larger than the specified input number digit length. Why is this? What would that quantity of array elements be?
  * perform the correct algorithm against the input:
    * generate carry values in an unsigned char **carry** array
    * propagate carry values against the sum values in the **sum** array
    * repeat until there are no further carry values to process
  * Display output showing aspects of the process (see example execution below)
    * ALL output, except the very final display of the number, should be displayed to STDERR
  * Output the final value (by iterating through the array, displaying one value at a time) to STDOUT

=====Execution=====
Several operating behaviors are shown as examples.

An eight digit value:

<cli>
lab46:~/src/cprog/mbe1$ ./mbe1
Enter value: 31415926
31415926 x 11 =         3   (3+1) (1+4) (4+1) (1+5) (5+9) (9+2) (2+6)   6
              =         3     4     5     5     6    14    11     8     6
              =         3     4     5     5   (6+1) (4+1)   1     8     6
              =         3     4     5     5     7     5     1     8     6
              = 345575186
lab46:~/src/cprog/mbe1$ 
</cli>

Next, a four digit value:

<cli>
lab46:~/src/cprog/mbe1$ ./mbe1
Enter value: 7104
    7104 x 11 =                                 7   (7+1) (1+0) (0+4)   4
              =                                 7     8     1     4     4
              = 78144
lab46:~/src/cprog/mbe1$ 
</cli>

Finally, a five digit value:

<cli>
lab46:~/src/cprog/mbe1$ ./mbe1
Enter value: 56789
   56789 x 11 =                           5   (5+6) (6+7) (7+8) (8+9)   9
              =                           5    11    13    15    17     9
              =                         (5+1) (1+1) (3+1) (5+1)   7     9
              =                           6     2     4     6     7     9
              = 624679
lab46:~/src/cprog/mbe1$ 
</cli>

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's some spacing at work in the program's output:

<cli>
Enter value: 967
     967 x 11 =                                       9   (9+6) (6+7)   7
              =                                       9    15    13     7
              =                                     (9+1) (5+1)   3     7
              =                                      10     6     3     7
              =                               (0+1)   0     6     3     7
              =                                 1     0     6     3     7
              = 10637
</cli>

With the exception of the final (packed together) 10637, everything is displayed to STDERR (that final 10637 is the **only** thing to display to STDOUT).

Some important things of note:
  * The input value should be //right justified// in an 8 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 '+' sign would be (so everything will line up in a digit-centered-like fashion).
    * if the number to display is a 2-digit number (10-19), its one's place needs to line up with the '+' sign.
    * 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.
    * 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 "whatever works"... so I am maintaining an exactness on my requirements for output to ensure we continue to establish these good habits.

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's output is in conformance with overall project specifications.

====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:~/src/cprog/mbe1$ ./mbe1 2>/dev/null <<< 64
704
lab46:~/src/cprog/mbe1$ 
</cli>

===4-digit result===
<cli>
lab46:~/src/cprog/mbe1$ ./mbe1 2>/dev/null <<< 512
5632
lab46:~/src/cprog/mbe1$ 
</cli>

===5-digit result===
<cli>
lab46:~/src/cprog/mbe1$ ./mbe1 2>/dev/null <<< 927
10197
lab46:~/src/cprog/mbe1$ 
</cli>

====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:
  * 78
  * 143
  * 2600
  * 31337
  * 191919
  * 8763243
  * 31415926

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:~/src/cprog/mbe1$ ./mbe1 <<< 78 2>output.78 1>>output.78
lab46:~/src/cprog/mbe1$ 
</cli>

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.78** 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 **mbe1** directory).

By using the **diff** command, you can see differences, if any. If there are no differences, the output matches (this is good, and what you want).

<cli>
lab46:~/src/cprog/mbe1$ diff output.78 /var/public/cprog/mbe1/output.78
lab46:~/src/cprog/mbe1$ 
</cli>

If you see output, that means there are differences, and that your output likely isn't in conformance with project specifications.

You can repeat this for the other data files (output.78 for an input of 78, etc.)

===Isolate just the STDOUT or the STDERR===
Additionally, you may want to specifically look at your program's STDOUT or STDERR independent of each other.

To do this, you can do the following.

To isolate STDOUT and STDERR into separate files, you can do the following:

<cli>
lab46:~/src/cprog/mbe1$ ./mbe1 <<< 78 1>stdout.78 2>stderr.78
lab46:~/src/cprog/mbe1$ 
</cli>

You can then compare those particular collections of information against my copies (located in the **mbe1** 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:~/src/cprog/mbe1$ pchk cprog mbe1
=====================================================
=           mbe1 output validation check            =
=====================================================

           stderr diff: MATCH    stderr md5sum: MATCH
[78]       stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH

           stderr diff: MATCH    stderr md5sum: MATCH
[143]      stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH

           stderr diff: MATCH    stderr md5sum: MATCH
[2600]     stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH

           stderr diff: MATCH    stderr md5sum: MATCH
[31337]    stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH

           stderr diff: MATCH    stderr md5sum: MATCH
[191919]   stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH

           stderr diff: MATCH    stderr md5sum: MATCH
[8763243]  stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH

           stderr diff: MATCH    stderr md5sum: MATCH
[31415926] stdout diff: MATCH    stdout md5sum: MATCH
           output diff: MATCH    output md5sum: MATCH
=====================================================
=      matches: 42, mismatches:  0, total: 42       =
=====================================================
lab46:~/src/cprog/mbe1$ 
</cli>

Since your project submission will be evaluated in part by compliance to output specifications, you probably want to check to see how you are doing before submitting.

=====Submission=====
To successfully complete this project, the following criteria must be met:

  * Code must compile cleanly (no warnings or errors)
    * I will be compiling as follows: gcc -Wall --std=c99 -o mbe1 mbe1.c
  * Output must be correct, and resemble the form given in the sample output above.
  * Code must be nicely and consistently indented (you may use the **indent** tool)
  * Code must utilize the algorithm presented 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
  * Track/version the source code in a repository
  * 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>
$ submit cprog mbe1 mbe1.c
Submitting cprog project "mbe1":
    -> mbe1.c(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.

What I'll be looking for:

<code>
78:mbe1:final tally of results (78/0)
*:mbe1:adequate indentation and comments in code [3/0]
*:mbe1:program correctly implements specified algorithm [8/0]
*:mbe1:input obtained from STDIN as single unsigned integer [4/0]
*:mbe1:program makes effective and central use of loops [8/0]
*:mbe1:sum array used appropriately in processing [8/0]
*:mbe1:carry array used appropriately in processing [8/0]
*:mbe1:processing output properly spaced and displayed to STDERR [8/0]
*:mbe1:final output displayed to STDOUT as packed individual digits [8/0]
*:mbe1:effective usage of fprintf() and fscanf() [8/0]
*:mbe1:runtime tests succeed [8/0]
*:mbe1:no negative compiler messages for code [3/0]
*:mbe1:code is pushed to lab46 repository [4/0]
</code>

Additionally:
  * 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 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