Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS1730 UNIX/Linux Fundamentals</fs></WRAP>
</WRAP>

======Project: GAUGING TASK FILES (gtf0)======

=====Errata=====

  * any bugfixes or project updates will be posted here

=====Objective=====
Working with familiar data (from having created it a few projects ago), we will now pursue avenues of compliance with TASK file specifications, performing general analysis, comparing across semesters, and other metrics.

=====Background=====
As is often the case, tasks we are given are not only meant to be accomplished, but also verified.

In the **upf0** project, we explored and created various **task#.cli** files which were to be viable solutions to problems using the **numbers** and **pipemath** tools within stated constraints.

We explored automating aspects of the process in the **upf0steps** file.

Now, we will specifically be looking at logic to verify that the solutions generated comply with the stated requirements of each problem (ie reference the TASK file and confirm the solution falls within acceptable bounds).

What's more, comparing one solution to others, even comparing one class to another are important skills in data analysis, allowing us to better realize patterns, trends, and other behaviors of the data (and users providing it).

=====The data=====
In the **gtf0/** sub-directory of the UNIX Public Directory are a number of sub-directories named after various semesters; for example, you may see things like:

  * spring2017/
  * fall2017/
  * spring2018/

Inside each of these directories is a set of additional directories, named numerically (ranging from 0 to some value, likely approaching 20).

And inside THAT directory you will potentially find all or some of the following:

  * TASK
  * task0.cli
  * task1.cli
  * task2.cli
  * task3.cli
  * task4.cli
  * task5.cli
  * task6.cli
  * task7.cli

I say //some//, because it is possible some directories will lack the task#.cli files (denoting an incomplete or non-existent submission).

You will be referencing the specific TASK file in each directory, to calibrate any logic used to evaluate the results.

NOTE: You do **NOT** want to copy this data. Reference it. This would be an __excellent__ application of variables.

=====Process=====
In the particular **TASK** file, there are a set of 8 tasks (ranging from 0 to 7) the provide specifications of command-lines that were to have been constructed to produce the desired outcome via particular means.

There are fields such as:

  * **result:** the final output desired from running the command-line contained in that task#.cli file.
  * **numbers:** specifications on which of the **numbers** tools can be used in the solving of the problem.
  * **operations:** specifications on which of the **pipemath** tools can be used in the solving of the problem.
  * **min_pipes:** indicates the __minimum__ number of pipes that MUST be present on the command-line to qualify as a valid solution.
  * **max_pipes:** indicates the __maximum__ number of pipes that MUST be present on the command-line to qualify as a valid solution.

All of these factors will need to be taken into account when determining the correctness and viability of a particular solution (and then to compare one solution's viability against that of others).

As was the case in **upf0**, the potential constraints are as follows:

  * **ANY:** no restrictions, any in applicable category can be used
  * **ONLY:** you are restricted to only those listed
  * **WITH_LIMITS:** usually providing specific restrictions within an **ANY** domain
  * **EXCEPT:** you are explicitly not allowed to use the listed; usually restricting an existing **ANY** domain
 
There may also be quantity limits on how many times you can use each number or operation. If so, such will be shown in parenthesis following the item in question.

As an example, we could have the following (formatted is it would appear in your **TASK** file):

<code>
task: 0
result: 4
numbers: ONLY(three(2), five, seven, nine)
operations: ANY
min_pipes: 2
max_pipes: ANY

</code>

With these constraints, we can set about verifying the provided solutions, checking whether the results generated, tools used, and pipes present conform with those stated requirements.

====Example====
For example, let's say we have 2 solutions to the above-listed task 0.

They are as follows:

<cli>
$ cat 0/task0.cli
seven | minus `three`
$ cat 1/task0.cli
three | minus `seven` | negate
$ 
</cli>

===Result===
First up, do they produce the desired result? We see from the task specification (in the **TASK** file), we need to get an output of 4.

Running the cli file (if present) will produce output, we can capture that and compare.

===Numbers===
We see that we are only allowed to use the three, five, seven, and nine numbers tools in the solution (and three at max only twice). We will need to make sure that only these valid tools are used (and also that no actual numbers have been placed instead of calling upon the tools).

===Operations===
Same situation with operations... the tools allowed may differ from problem to problem.

===minimum pipes===
We'll see here that, if both problems are subject to that same task 0 specification, the first one is in violation- for it only has a single pipe in its command-line.

We will need to perform an inventory on the pipes to make sure this requirement has been met.

===maximum pipes===
Similar case here as with minimum pipes.

===conclusion===
Once we have performed these tests on a problem, we can tally up and compute the result, so we can compare it to others.

=====Process: The script=====
You are to create a **gtf0.sh** script which will manage the evaluation and reporting of various results.

It is to have the following options:


=====Submission=====
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 **upf0steps** file.

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

<cli>
$ submit unix upf0 upf0steps task*.cli
Submitting unix project "upf0":
    -> upf0steps(OK)
    -> task0.cli(OK)
    -> task1.cli(OK)
    -> task2.cli(OK)
    -> task3.cli(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.

I'll be looking for the following:

<code>
78:upf0:final tally of results (78/78)
*:upf0:upf0steps has valid list of non-interactive instructions [4/4]
*:upf0:upf0steps only copies/alters files if USER matches [4/4]
*:upf0:upf0steps builds the various task#.cli files it runs [4/4]
*:upf0:upf0steps obtains the latest pipemath release from site [4/4]
*:upf0:upf0steps only displays specified STDOUT output [4/4]
*:upf0:upf0steps resiliently creates local project directory [4/4]
*:upf0:upf0steps copies public dir data with absolute path [4/4]
*:upf0:upf0steps makes clear, effective use of wildcards [4/4]
*:upf0:upf0steps has descriptive why and how comments [4/4]
*:upf0:upf0steps indentation used to promote scope and clarity [2/2]
*:upf0:upf0steps defines and uses custom variables [4/4]
*:upf0:upf0steps uses command expansions to get information [4/4]
*:upf0:upf0steps uses a loop to drive numbers in final output [4/4]
*:upf0:upf0steps automates the task when run [4/4]
*:upf0:all files are organized, clear, and easy to read [4/4]
*:upf0:task#.cli files output only correct, specified data [4/4]
*:upf0:task#.cli files use specified number tools by quantity [4/4]
*:upf0:task#.cli files display no STDERR output [4/4]
*:upf0:task#.cli files have solution within given constraints [4/4]
*:upf0:task#.cli files only have the solution command-line [4/4]
</code>

<code>
78:gtf0:final tally of results (78/78)
*:gtf0:gtf0.sh effectively utilizes variables in operations [4/4]
*:gtf0:gtf0.sh effectively utilizes command expansions [4/4]
*:gtf0:gtf0.sh effectively utilizes regular expressions [4/4]
*:gtf0:gtf0.sh effectively utilizes wildcards in operations [4/4]
*:gtf0:gtf0.sh effectively utilizes selection statements [4/4]
*:gtf0:gtf0.sh effectively utilizes looping structures [4/4]
*:gtf0:gtf0.sh effectively utilizes functions in script [4/4]
*:gtf0:gtf0.sh effectively utilizes arrays in script [4/4]
*:gtf0:gtf0.sh is a proper bash script with shabang and exit [4/4]
*:gtf0:gtf0.sh parses command-line arguments as appropriate [4/4]
*:gtf0:gtf0.sh processes all files within given scope [4/4]
*:gtf0:gtf0.sh determines accuracy of results [4/4]
*:gtf0:gtf0.sh determines accuracy of numbers tools used [4/4]
*:gtf0:gtf0.sh determines accuracy of pipemath tools used [4/4]
*:gtf0:gtf0.sh determines accuracy of min_pipes utilized [4/4]
*:gtf0:gtf0.sh includes additional bases as requested [4/4]
*:gtf0:gtf0.sh omits specified bases as requested [4/4]
*:gtf0:gtf0.sh operates according to specifications [5/5]
*:gtf0:gtf0.sh logic is organized and easy to read [5/5]
</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
Lab46 Wiki

User Tools

Site Tools

Page Tools
