Differences

This shows you the differences between two versions of the page.

--- haas:fall2023:discrete:projects:blf0 [2024/04/11 12:46] – created wedge
+++ haas:fall2023:discrete:projects:blf0 [2024/04/12 07:18] (current) – [Process] wedge
@@ Line 7: / Line 7: @@
 =====OBJECTIVE=====
-To apply bitwise logic in the application of decoding IEEE754-encoded 32-bit values, displaying the decoded result.
+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>
+: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