Differences

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

--- haas:fall2023:discrete:projects:blf0 [2024/04/11 13:02] – 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 integer data. The format for unsigned data is straightforward.
+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.
@@ Line 16: / Line 24: @@
 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:ieee-754-english.jpg|}}
+{{: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:
@@ Line 62: / Line 140: @@
 <code>
-:blf0:final tally of results (286/286)
+:blf0:final tally of results (52/52)
-*:blf0:submitted C and assembly implementations [26/26]
+*:blf0:implementation builds cleanly [13/13]
-*:blf0:each implementation builds cleanly [26/26]
+*:blf0:output conforms to specifications [13/13]
-*:blf0:output conforms to specifications [26/26]
+*:blf0:processing is correct, and to specifications [13/13]
-*:blf0:processing is correct, and to specifications [26/26]
+*:blf0:provided example worked through on documentation [13/13]
-*:blf0:working break on composite optimization [26/26]
-*:blf0:working odds only processing optimization [26/26]
-*:blf0:working sqrt factor cap optimization [26/26]
-*:blf0:all variants and combinations thereof operational [26/26]
-*:blf0:graph produced from timing data produced [26/26]
-*:blf0:graph posted to discord and documentation page [26/26]
-*:blf0:timing data is taken out to 3 decimal places [26/26]
 </code>
@@ Line 95: / Line 166: @@
   * 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