• revision #: <description> (DATESTAMP)

To continue to cultivate your problem solving, critical thinking, analytical, and observation skills; to apply your skills on the UNIX command-line.

The true nature of problem solving frequently involves critical thinking, analytical, and observation skills. Where problems are not solved by memorizing some pre-defined set of answers and regurgitating them mindlessly, but it crafting an elaborate solution from subtle cues and tested, experimental realizations.

This project has puts you in contact with such endeavours.

Letter division is a category of logic problem where you would take an ordinary math equation (in long form), and substitute all the numbers for letters, thereby in a direct sense masking the numeric values present that correctly enable the problem to work from start to completion. It is your task, through exploring, experimenting, and playing, to ascertain the numeric value of each letter (as many as 10, one for each numeric value 0-9).

For this project we will be focusing on long division, something you learned (and perhaps last experienced, before becoming mindlessly addicted to pressing buttons on a calculator, in grade school). It entails a whole number (integer) division, involving aspects of multiplication, addition (through borrowing), and subtraction (primarily) to arrive at a quotient and a remainder.

Division is unique in that it produces two 'answers', each serving particular uses in various applications.

Here is an example (using numbers):

First up, we're going to divide 87654321 (the dividend) by 1224 (the divisor). Commonly, especially if punching into a calculator, we might express that equation as:

87654321/1224

Or in a language like C, assigning the quotient to the variable x (an integer):

    x = 87654321/1224;

But, we're not actually interested in the 'answer' (quotient or remainder); we are interested in the PROCESS. You know, the stuff the calculator does for you, which in order to perform this project and better explore the aspects of critical thinking, we need to take and encounter every step of the way:

          71613
     +---------
1224 | 87654321
      -8568
       ====
        1974
       -1224
        ====
         7503
        -7344
         ====
          1592
         -1224
          ====
           3681
          -3672
           ====
              9

Here we obtain the results (focusing on the quotient up top; as the remainder quite literally is what remains once we're done- we're specifically NOT delving into decimal points, but instead doing integer division, which as previously stated has MANY important applications in computing) through a step by step process of seeing how many times our divisor (1224) best and in the smallest fashion fits into some current value of the dividend (or intermediate result thereof).

For instance, seeking the smallest “best fit” of 1224 into 87654321, we find that 1224 fits best SEVEN times (1224 * 7 = 8568, which is the CLOSEST we can get to 8765… 1224 * 8 = 9792, which would be too big (and way too small for 87654). Clearly, we are seeking those values that best fit within a multiple of 0-9, staying away from double digits of multiplication (although, we COULD do it that way and still arrive at the same end result).

So: 8765-8568 = 197.

We have our first result, yet: there's still values in the dividend (87654321) remaining to process, specifically the 4321, so we take them one digit at a time.

The next available, unprocessed digit in 4321 is '4', so we 'drop that down' and append it to our previous result (197), giving us: 1974.

We now see how many times (via single digit multiplication), our divisor (1224) can fit into 1974. As it turns out, just once.

So: 1974-1224 = 750.

And we keep repeating the process until there are no more digits from the dividend to drop down; at which point, we are left with a remainder (in the above problem, the lone '9' at the very bottom; THAT is the remainder).

Clearly it is important to have a handle on and understanding of the basic long division process before attempting a letter division problem. So, be sure to try your hand at a few practice problems before proceeding.

Following will be a sample letter division problem, and a documented work through of it, much as you will be doing for this project (and to be sure: the aim here is not merely to solve it, but to DOCUMENT HOW YOU SOLVED IT, so just like the 'steps' files you did in various projects, you might want to keep notes as you go along to save you time and sanity).

Here goes:

            GLJK
      +---------
 KJKK | GLMBRVLR
       -VKOKL
        =====
         LJBGV
        -OKVKG
         =====
          JJGKL
         -LKBKV
          =====
           KVRMR
          -JKRKB
           =====
            VKMK

First off, note how this is NO DIFFERENT from the numeric problem above: just instead of numbers, which we've associated some concepts with, here we have letters (each letter maps to a unique number, 0-9). The trick will be to figure out which letter maps to which number.

So, let us begin:

This week's project has 2 points of origin.

First, in the upf1/ sub-directory of the UNIX Public Directory, under a directory by the name of your username, you will find the following file:

• TASK

Copy this file into your project directory.

The TASK file will contain the particular units to start with and convert to.

Next, you will want to grab the latest version of the unittools suite from the following URL:

• https://lab46.g7n.org/~wedge/projects/unittools/

You will want to use a tool like wget(1) or curl(1) to non-interactively download it onto your lab46 account, and similarly extract, compile, and install that (check its own README file).

There may be multiple versions of unittools available at the download link. Unless you have specific reason otherwise (for this project, you do not), you want to go for the latest version, which will be reflected by the most recent datestamp encoded in the file's name.

For example, say you have the following:

• unittools-20160731-10.tar.gz
• unittools-20161024-14.tar.gz
• unittools-20170123-13.tar.gz
• unittools-20170201-09.tar.gz

From visual inspection, you would select the “20170201-09” one, because the date it encodes (Feb 1st, 2017 at 9am) is the most recent in that group. You will find this to be a common practice with many software projects on the internet.

Note, however, that visual inspection alone is not good enough for your steps file. New versions may be released, and your steps file needs to obtain the most recent version available. To facilitate this task, the latest and greatest version of unittools will be listed in a file called LATEST (which you should see near the top of the directory index listing). You can make use of this file to assist you in automating the process of determining and downloading the latest version of the unittools tools.

Once those two steps are complete, you can begin on the tasks listed in your TASK file.

The unittools suite is a collection of command-line tools that perform various unit conversions you may find useful for this project. The tools include:

• cm2in - convert centimeters to inches
• cu2mm - convert cubits to millimeters
• dm2cm - convert decimeters to centimeters
• Dm2mi - convert Decameters to miles
• ft2hm - convert feet to hectometers
• ft2yd - convert feet to yards
• hm2dm - convert hectometers to decimeters
• hm2Dm - convert hectometers to Decameters (if not available, use hm2dcm instead)
• in2cu - convert inches to cubits
• in2ft - convert inches to feet
• km2ft - convert kilometers to feet
• mi2km - convert miles to kilometers
• mi2yd - convert miles to yards
• mm2dm - convert millimeters to decimeters
• st2mi - convert stadions to miles
• yd2mi - convert yards to miles
• yd2st - convert yards to stadions

The tools by default expect input via STDIN, and will output to STDOUT.

These tools have command-line arguments which can alter their default behavior. You may want to review the options and defaults (try running them with the -h argument to see what sort of functionality is available).

In the TASK file, you will be given a set of source quantities/units and destination units you need to construct command-lines for to solve, using the tools provided to you in the unittools suite. You will also want to make use of pipes and command expansions in your solutions.

As an example, take the following (formatted is it would appear in your TASK file):

task: 0
precision: 3
input_value: 35
input_unit: cm
output_unit: ft
chain_delim: " >> "

With these in mind, we can set about solving this problem, using the tools in combination to arrive at the desired result.

A potential solution would be as follows:

lab46:~/src/unix/upf1$ echo "35" | cm2in
13.78 in
lab46:~/src/unix/upf1$ echo "13.78" | in2ft
1.15 ft
lab46:~/src/unix/upf1$ 

But that's not very optimized. We could instead do something better, like:

lab46:~/src/unix/upf1$ echo "35.000 cm" | cm2in OPTIONS | in2ft OPTIONS
35.000 cm >> 13.780 in >> 1.148 ft
lab46:~/src/unix/upf1$ 

Note that with precision, you need to instruct the tools to display out to the specified number of decimal places.

We'll want to record our command-lines in the appropriate place. Since this is task #0, we'll want to record it in a file called: task0.cli, which should basically just contain the command-lines you ran, merely placed in a text file.

For final output, we'll want to display the chain of conversions we went through. So, for this above example:

lab46:~/src/unix/upf1$ ./task0.cli
35.000cm >> 13.780in >> 1.148ft
lab46:~/src/unix/upf1$ 

Basically, each task#.cli will be its own script. If we were to execute it, the correct result should be produced.

You will once again be creating a steps file that can automate your project (ie it contains a list of non-interactive steps to complete the task).

As in previous projects, upf1steps will contain the steps you took from the point of copying the numbers suite and downloading the unittools suite up until the submit step (hint: just run the task#.cli scripts within the steps script).

• To clarify: YES, I want to see steps creating a project directory, copying and downloading files in question, extracting, compiling, installing, and then of course running each individual task#.cli script.

There are some additional constraints you need to keep in mind:

• your script should not produce ANY STDERR output
• your script should ONLY produce STDOUT output in conformance with the below stated requirements. Any other output needs to be silenced.
• You will want one unified command-line producing the end result, not separate one-step transitions. The idea is to utilize pipes.
  • semi-colons used to separate commands do not constitute one command-line, but several.
• For each task, you'll want to display things as follows:
  • “Task X conversion chain: CHAIN”
    • where X is the task number (0, 1, 2, etc.)
    • where CHAIN is the conversion chain output matching the TASK file result requested (ie, you must run your task#.cli script to produce this output).
      • note that the task#.cli output appears on the SAME line as the “Task X conversion chain:” text, and there is a single space separating it from the colon.
      • there is NO space between value and unit

For example, a sample output of your upf1steps script should appear like follows (but your # values will of course be different based on your individual TASK file):

lab46:~/src/unix/upf1$ ./upf1steps
Task 0 conversion chain: 35.000cm >> 13.780in >> 1.148ft
...
lab46:~/src/unix/upf1$ 

By successfully performing this project, you should have a set of task#.cli files (one for each task). You will want to submit these, along with a upf1steps file.

To submit this project to me using the submit tool, run the following command at your lab46 prompt:

$ submit unix upf1 upf1steps task*.cli
Submitting unix project "upf1":
    -> upf1steps(OK)
    -> task0.cli(OK)
    -> task1.cli(OK)
    -> task2.cli(OK)
    -> task3.cli(OK)
       ...

SUCCESSFULLY SUBMITTED

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:

78:upf1:final tally of results (78/78)
*:upf1:upf1steps has valid list of non-interactive instructions [4/4]
*:upf1:upf1steps only copies/alters files if USER matches [4/4]
*:upf1:upf1steps builds the various task#.cli files it runs [4/4]
*:upf1:upf1steps obtains the latest pipemath release from site [4/4]
*:upf1:upf1steps only displays specified STDOUT output [4/4]
*:upf1:upf1steps resiliently creates local project directory [4/4]
*:upf1:upf1steps copies public dir data with absolute path [4/4]
*:upf1:upf1steps makes clear, effective use of wildcards [4/4]
*:upf1:upf1steps defines and uses custom variables [4/4]
*:upf1:upf1steps uses command expansions to get information [4/4]
*:upf1:upf1steps uses a loop to drive numbers in final output [4/4]
*:upf1:upf1steps automates the task when run [4/4]
*:upf1:all files are organized, clear, and easy to read [4/4]
*:upf1:task#.cli files output using specified precision [3/3]
*:upf1:task#.cli files output using specified delimiter [3/3]
*:upf1:task#.cli files output only correct value and unit [4/4]
*:upf1:task#.cli files output in specified format [4/4]
*:upf1:task#.cli files display no STDERR output [4/4]
*:upf1:task#.cli files have solution within given constraints [4/4]
*:upf1:task#.cli files only contain the solution command-line [4/4]

Additionally:

• 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