PROJECT: Units Of Measurement (UOM0)

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:

+---------+-----------------+
|  prefix |  value          |
+---------+-----------------+
|  kilo   |  1000           |
|  mega   |  1000000        |
|  giga   |  1000000000     |
|  tera   |  1000000000000  |
+---------+-----------------+

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:

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

Put side by side, we see:

+------------------+---------------------------------------------+
|  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      |
+------------------+---------------------------------------------+

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)

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)

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$ 

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”

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.

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.

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):

lab46:~/src/fall2021/discrete/uom0$ make submit

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:

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]

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