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%>CSCS2330 Discrete Structures</fs></WRAP>
</WRAP>

======PROJECT: Bitwise Logic Floats (BLF0)======

=====OBJECTIVE=====
To use bitwise logic in the application of decoding IEEE754-encoded 32-bit values, displaying the decoded result.

=====READING=====
Please consult the following resources to get a better feel on floating point and the IEEE754 standard:

  * https://en.wikipedia.org/wiki/IEEE_754
  * https://www.puntoflotante.net/FLOATING-POINT-FORMAT-IEEE-754.htm
  * [[https://www.sciencedirect.com/topics/engineering/floating-point-number#:~:text=The%20mantissa%20is%2023%20bits,%E2%88%923%20%3D%207%2F8.|sciencedirect]]
  * https://www.h-schmidt.net/FloatConverter/IEEE754.html

=====BACKGROUND=====
Much of our experience transacting in numbers on the computer has been with whole number/integer data. The format for unsigned data is straightforward.

Signed quantities undergo a process known as two's complement, which can be encoded/decoded to decipher the value stored within.

Floating point data also has an encoding scheme for storage. There are actually a few different floating point standards. One of the common, classic ones frequently found in use is that of IEEE754, which we will focus on in this project.

{{:haas:fall2023:discrete:projects:ieee754-binary-wikipedia.png|binary layout of IEEE754 (sourced from wikipedia article)}}

====Process====
Walking through the decoding scheme, we'll start with an instance of IEEE754-encoded data: **0xC378C000**

The first step is to visualize it in binary so we can proceed to divide it into its distinct components. Doing a simple hexadecimal to binary conversion yields:

^  C  ^  3  ^  7  ^  8  ^  C  ^  0  ^  0  ^  0  |
|  1100  |  0011  |  0111  |  1000  |  1100  |  0000  |  0000  |  0000  |

Then, we carve up that 32-bit value according to the IEEE754 standard:

^  sign (bit 31)  ^  exponent (bits 30-23)  ^  mantissa (bits 22-0)  |
|  1  |  <nowiki>100 0011 0</nowiki>  |  <nowiki>111 1000 1100 0000 0000 0000</nowiki>  |

===Determine the exponent===
In this example, we have **<nowiki>1000 0110</nowiki>** or **0x86** in our exponent section.

What we do now is take that value, and subtract a **0x7F** from it to get our actual exponent value:

  * **0x86-0x7F = +7**

===Set up our mantissa for exponent processing===
We then start to setup our whole number value, which conceptually is to the immediate left of the mantissa. We assign a 1 to it by default. As a result, our floating point value (in binary) is currently:

  * <nowiki>1 . 111 1000 1100 0000 0000 0000</nowiki>

===bit shift by exponent===
If our exponent value is positive, we **LEFT SHIFT** by that many bits. If negative, we **RIGHT SHIFT**.

In our case, our exponent value was a +7, so we will **LEFT SHIFT** by 7. Each bit that goes off the left end of the mantissa pops over into the value to the left of the decimal point.

Step-by step, our 24 total bits will progress as follows:

  * original: <nowiki>1 . 111 1000 1100 0000 0000 0000</nowiki>
  * left shift by 1 (1): <nowiki>11 . 11 1000 1100 0000 0000 0000</nowiki>
  * left shift by 1 (2): <nowiki>111 . 1 1000 1100 0000 0000 0000</nowiki>
  * left shift by 1 (3): <nowiki>1111 .  1000 1100 0000 0000 0000</nowiki>
  * left shift by 1 (4): <nowiki>11111 .  000 1100 0000 0000 0000</nowiki>
  * left shift by 1 (5): <nowiki>111110 .  00 1100 0000 0000 0000</nowiki>
  * left shift by 1 (6): <nowiki>1111100 .  0 1100 0000 0000 0000</nowiki>
  * left shift by 1 (7): <nowiki>11111000 .   1100 0000 0000 0000</nowiki>

===determine value to the left of the decimal point===
The value we have to the left of the decimal point is **<nowiki>11111000</nowiki>**, which when converted to decimal is **248**.

We prefix the sign to this (1 indicates negative, which in this example it was), so: **-248.**

===determine the fractional value===
Now, to get the component to the right of the decimal point, we basically add together the bit positions, which correspond to **1/2^-position**, where position starts at 1.

So, with our current value of **<nowiki>1100 0000 0000 0000</nowiki>**, we have exactly 2 values containing a 1. Positions 1 and 2.

According to our formula:

  * fraction = <nowiki>0</nowiki>
  * fraction = <nowiki>fraction + (1/(2^-1))</nowiki>
  * fraction = <nowiki>fraction + (1/(2^-2))</nowiki>

As it turns out, <nowiki>(1/(2^-1)) = 0.5</nowiki>, and <nowiki>(1/(2^-2)) = 0.25</nowiki>, so:

  * fraction = 0
  * fraction = 0 + 0.5 = 0.5
  * fraction = 0.5 + 0.25 = 0.75

We them put everything together:

  * <nowiki>- 248 . 75</nowiki>

Therefore, **0xC378C000** decodes as **-248.75**
=====TASK=====
Your task is to write a program that will take in various encoded IEEE754 binary values, and to decode and ultimately display the decoded value.

You will be given a distinct list of floating point values that you will have to decode.
=====EDIT=====
You will want to go [[/notes/discrete/fall2024/projects/blf0|here]] to edit and fill in the various sections of the document:

  * [[/notes/discrete/fall2024/projects/blf0|https://lab46.g7n.org/notes/discrete/fall2024/projects/blf0]]

{{page>notes:discrete:fall2024:projects:blf0&nouser&nodate&nomdate&editbtn}}

=====SUBMISSION=====
To be successful in this project, the following criteria (or their equivalent) must be met:

  * Project must be submit on time, by the deadline.
    * Late submissions will lose 33%  credit per day, with the submission window closing on the 3rd day following the deadline.
  * 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 consistently written, to strive for readability from having a consistent style throughout
  * 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 (without instructor approval), no goto statements, no 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 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:

<cli>
lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN
</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.

=====RUBRIC=====
I'll be evaluating the project based on the following criteria:

<code>
52:blf0:final tally of results (52/52)
*:blf0:implementation builds cleanly [13/13]
*:blf0:output conforms to specifications [13/13]
*:blf0:processing is correct, and to specifications [13/13]
*:blf0:provided example worked through on documentation [13/13]
</code>

===Pertaining to the collaborative authoring of project documentation===

  * each class member is to participate in the contribution of relevant information and formatting of the documentation
    * minimal member contributions consist of:
      * near the class average edits (a value of at least four productive edits)
      * near the average class content change average (a value of at least 1024 bytes (absolute value of data content change))
      * no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements)
    * adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    * content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      * no contributions, co-efficient is 0.50
      * less than minimum contributions is 0.75
      * met minimum contribution threshold is 1.00

===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 or otherwise maintaining consistency in code style and presentation 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