<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS2330 Discrete Structures</fs></WRAP>
</WRAP>

======PROJECT: Units Of Measurement (UOM0)======

=====Background=====
In  computing, we're  constantly interacting  with data  and information.
While these  terms are frequently  interchanged, they actually  both hold
useful and distinct meanings.

The word "data"  is defined as meaning: **the  quantities, characters, or
symbols on which operations are performed by a computer, being stored and
transmitted in the  form of electrical signals and  recorded on magnetic,
optical, or mechanical recording media.**

The  word "information",  on the  other hand,  is defined  as: **what  is
conveyed  or  represented by  a  particular  arrangement or  sequence  of
things. It is  the result of data being organized,  processed, stored, or
transmitted by a computer.**

For example, "data" might refer to some quantity of 1s and 0s stored on a
disk. "Information", on  the other hand, is applying  some larger context
or  pattern to  that otherwise  meaningless sequence  of bits.  A set  of
numbers  can be  construed  as data,  whereas a  list  of prime  numbers?
Information.

Another  defining characteristic  of information  is that  we can  use it
to  better  communicate ideas.  As  there  is  no single  perspective  or
point of  reference on all  information, to avoid  becoming unnecessarily
long-winded, we  enhance our information  even more with the  addition of
units-- further classifications  that we can use to  compare and evaluate
information.

Look around:  information in the world  is filled with units.  We rely on
units to  convey information: how many  **miles per hour** are  we going?
How many **litres** of water can be  placed in a container? How much does
that item weigh (factor in shipping costs)?

And misunderstanding units can lead to miscommunication, from losing Mars
rovers  to  receiving unexpected  overcharge  fees  on cell  phone  bills
(https://www.youtube.com/watch?v=MShv_74FNWU).

In the realm of computing, we  quantify our information in units of bits.
Now, we seldom  relate information in bits, but instead  easier to manage
units like bytes, kilobytes, megabytes, etc.

At the  simplest level, most  of us understand  that (at least  in recent
decades) 1  byte is equal  to 8 bits. But  so often, our  typical storage
capacities are  huge and expressing  them in  just bytes would  be rather
unwieldy-  instead we  further  simplify by  using kilobytes,  megabytes,
gigabytes, etc.

Using the metric system, we recognize the following prefixes:

<code>
+---------+-----------------+
|  prefix |  value          |
+---------+-----------------+
|  kilo   |  1000           |
|  mega   |  1000000        |
|  giga   |  1000000000     |
|  tera   |  1000000000000  |
+---------+-----------------+
</code>

Historically, however, due to the  computer's grouping of 8-bits per byte
(instead  of other  measurements which  we group  in collections  of 10),
which meant  that instead  of a  kilobyte being 1000  bytes, it  was 1024
bytes.

In  recent years,  the metric  gestapo convinced  the computing  realm to
similarly line  up to even units  of 10. Marketing people  loved this, as
they could  now sell you  a 1TB hard drive  but there'd actually  be less
capacity than was historically sold.

To retain context,  a new class of units were  created to encapsulate the
old 8-based byte storage. These received a lowercase "i" in their unit:

<code>
+------------------+---------------------------------------------+
|  prefix          |  value                                      |
+------------------+---------------------------------------------+
|  kibiByte (kiB)  |  1024                                       |
|  MibiByte (MiB)  |  1024 * 1024 = 1048576                      |
|  GibiByte (GiB)  |  1024 * 1024 * 1024 = 1073741824            |
|  TibiByte (TiB)  |  1024 * 1024 * 1024 * 1024 = 1099511627776  |
+------------------+---------------------------------------------+
</code>

Put side by side, we see:

<code>
+------------------+---------------------------------------------+
|  prefix          |  value                                      |
+------------------+---------------------------------------------+
|  kilobyte (kB)   |  1000 bytes                                 |
|  kibiByte (kiB)  |  1024 bytes                                 |
|  MegaByte (MB)   |  1000 * 1000 = 1000000 bytes                |
|  MibiByte (MiB)  |  1024 * 1024 = 1048576 bytes                |
|  GigaByte (GB)   |  1000 * 1000 * 1000 = 1000000000 bytes      |
|  GibiByte (GiB)  |  1024 * 1024 * 1024 = 1073741824 bytes      |
+------------------+---------------------------------------------+
</code>

=====units=====
Your program will recognize at least the following units of data:

  * bits (smallest unit)
  * bytes (1 byte == 8-bits)
  * deka(bits|bytes) (D(b|B) -- groups of 10)
  * dibi(bits|bytes) (Di(b|B) -- groups of 16)
  * hecto(bits|bytes) (H(b|B) -- groups of 100 (10*10))
  * hibi(bits|bytes) (Hi(b|B) -- groups of 128 (16*8))
  * kilo(bits|bytes) (k(b|B) -- groups of 1000 (10*10*10))
  * kibi(bits|bytes) (ki(b|B) -- groups of 1024 (16*8*8))
  * Mega(bits|bytes) (M(b|B) -- 1000000)
  * Mibi(bits|bytes) (Mi(b|B) -- 1024*1024)
  * Giga(bits|bytes) (G(b|B) -- 1000*1000*1000)
  * Gibi(bits|bytes) (Gi(b|B) -- 1024*1024*1024)
  * Tera(bits|bytes) (T(b|B) -- 1000*1000*1000*1000)
  * Tibi(bits|bytes) (Ti(b|B) -- 1024*1024*1024*1024)

=====Task=====
Write a program that prompts the user for 3 pieces of input:

  * a number (which will be some form of the listed units you are working with)
  * the unit of that number (any from the above in the list of units)
  * the unit to convert that source input to (any from the above units)

====Example output, units of data====
<cli>
lab46:~/src/SEMESTER/discrete/uom0$ ./uom0
Enter source value: 2048
Enter source unit: kiB
Enter destination unit: Db

2048 kiB == 1677721.6250 Db
lab46:~/src/SEMESTER/discrete/uom0$ 
</cli>

=====Verification=====
For additional help in attaining output and formatting compliance, I have
included  a  copy  of  a  working implementation,  which  abides  by  the
project specifications.  Please compare its  output against that  of your
implementation.

Run the  provided "verify"  program with  whatever combination  of inputs
needed to obtain the output that your implementation needs to reproduce.

You can run the verify program with "make check"

=====Additional requirements=====
In your finished, submitted product:

  * program should be called: **uom0.c**
  * program should be located in a uom0/ directory.
  * submit by running "make submit" in the base uom0/ directory on lab46.
  * specific  output  to  STDOUT  vs STDERR  is  important,  as  is   the formatting of output in regards to justification and spacing. In this program, all information is to be displayed to STDOUT.

The resultant program MUST  be well-organized, easy-to-read, consistently
indented  visually  showing the  encapsulated  levels  of logic,  and  be
thoroughly commented to explain each significant step of the process.

=====Submission Criteria=====
To be successful in this project, the following criteria must be met:

  * Project must be submit on time, by the posted deadline.
    * Late submissions will lose 33%  credit per day, with the submission window closing on the 3rd day following the deadline.
  * All code must compile cleanly (no warnings or errors)
    * Compile with the **-Wall** and **--std=gnu18** compiler flags
    * all  requested functionality  must conform  to stated  requirements (either on  this README or  in 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 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, no goto statements, no manual 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.

====Submit Tool Usage====
Let's  say you  have completed  work  on the  project, and  are ready  to
submit, you  would do the following  (assuming you have a  program called
uom0.c):

<cli>
lab46:~/src/fall2021/discrete/uom0$ 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 evaluating the project based on the following criteria:

<code>
52:uom0:final tally of results (52/52)
*:uom0:grabbed project by the Sunday before due date [6/6]
*:uom0:clean compile, no compiler messages [10/10]
*:uom0:runtime tests pass [20/20]
*:uom0:adequate modifications [10/10]
*:uom0:tracked in lab46 semester repo [6/6]
</code>

Additionally:

  * Solutions not abiding  by spirit of project will be  subject to a 50% 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