We probably fucking are xD but I had this shit last semester and already passed so unless you're going with past-me, I don't know what's going on. The theory that we have different teachers who happen to be equally lazy is too ridiculous, right?
The bias is 15 for 16 bit floats (like the GPU sometimes uses), 127 for 32 bit floats, 1023 for 64 bit doubles and 16383 for 80 bit extended precision (like our x87 FPU uses). Each of the different sized floats has it's own predefined bias. I guess they had a choice, the exponent field gives magnitude and the mantissa gives precision, they figured an 8 bit exponent and 23 bit mantissa was a good balance between the two.
By the way, folks, the exponent is biased because it is a two's complement number, which is difficult to order from least to greatest without the offset--ordering allows for easy comparison, which simplifies CPU operations. Since the exponent in single-precision floating point format is eight bits wide, the maximum possible bit combinations it can represent is 2^8 = 256. The "complement" of an eight bit number A is the result when you subtract A from 256. Thus, the complement of 50 is 256 - 50 = 206. To represent negative numbers, then, we can use the complement of the positive binary number. -50 in binary becomes 11001110 (which is 206 unsigned). It should be clear enough that the maximum possible complements are 128: if you begin at zero (whose complement is 256, with most significant bit ignored), you find that you exhaust them all once you arrive at 127. Thus, positive numbers range from 1 to 127, while negatives range from -1 to -128. Because 0 and 255 are reserved with special meanings, our actual number of possible exponents is 254, which range from -126 to +127. (Divide 254 by 2, giving 127. 0 and 255 are unavailable. Most negative possible value: 1 - 127 = -126. Most positive: 254 - 127 = 127.) Adding 127 to the true value results in a range of numbers from 1 to 254, which is much simpler for comparative purposes.
I had 5 minutes to understand this before my exam because I totally missed that this might be a part of it. The float question was so easy I think I actually got it thanks to the first minutes of this video. Thanks fam.
Thank you very much for this video! I came here after studying Java and wondering how large a float/double is. After being confused by wikipedia, your video instantly helped me understand. Subscribed and will be consuming your very interesting AES encryption videos shortly!
Single-precision floating-point format is a computer number format that occupies 4 bytes (32 bits) in computer memory and represents a wide dynamic range of values by using a floating point. In IEEE 754-2008 the 32-bit base-2 format is officially referred to as binary32. It was called single in IEEE 754-1985.
Awesome video, helped me understand how to do the IEEE representation. I was so stuck on this trying to understand my professor's lecture video. You went slowly step by step, awesome job!! There is one thing I would like to say though for the improvement. The part where you discovered that 1.35703125 is ''normalized'', I think it would be good to mention or at least make explicit that the initial ''1'' is not counted in the 23 bits. I would say that after you put that first 1, then you start counting 23 slots after that. But great job and keep up the good work!!
For clarification, finding the power of 2 needed to normalize the value of 173.7 is done by performing - log2(173.7), and then to find the normalized value (1.35703125) perform - 173.7/log2(173.7)
Awesome video. The first part is that u r answering the questions?? I understands it very well by looking at the questions being asked and how well explained are ur replies. Thanks for ur time . God bless u
Are you planning to do a video on floating point arithmetic; add, subtract, multiply and maybe tougher ones like divide or square root? Would be very interesting.
Assuming you're talking about two IEEE f loats? You'll want to look at operations on scientific notation numbers. If the exponents are the same you can add the mantissas and normalise, don't forget the implied bit. If the exponents differ you have to multiply one of the numbers by a power of 2 till the powers are the same, then add the mantissas and normalise. Hope this helps, thanks for watching.
Thanks! Exactly what I needed for my test. Now if you could do a tutorial on how to write a 4-function calculator in x86 ISA, I'd be in your debt haha.
For something like the atof C++ function each version would be different depending on which headers and libraries the compiler is using. Converting a binary int to IEEE is very easy with a few shifts. Thanks for watching and commenting!
Hello there, nice video, but I still got one question : ) I hope I'll get an answer even if this video is a little older. I'd like to know, if there is a system to calculate a hexadecimal representation of a (single/double) float into decimal and vice versa without determining the binary representation. Or isn't that possible, at all? ^^ Thanks in advance.
Yup, I think What's a Creel? should add an annotation there, honestly. Great video, but that bit might confuse those that aren't listening to the audio. Totally didn't think of that though while watching
Yeah that's my screen recorder, CamStudio, it's good but for some reason when there's not a lot of graphics in the lower portion of the screen it flashes like this. It's in the original mpeg as well. I try to make fairly busy slides to avoid it but it still happens sometimes. I hope it's not too distracting...
I think I've not been clear... Once the digit 1 is recorded I subtract it from the amount we're still to explain. When I say subtract here I don't mean subtract from the bit pattern we've recorded in the mantissa, I mean from the amount we've left to describe. 0.5x2 is 1.0, we record the 1 in the mantissa then subtract it from the amount we've left to describe to get 0.0. Hope this makes sense, thanks for watching and commenting.
How rude of me. They're all basically the same system. I'm not sure how they came up with the sizes of exponent and mantissa, there seems to be no definite pattern. I guess they just went with what seemed most versatile and useful. The 64 bit for instance has an 11 bit exponent when (if it was to share the ratio of bits to exponent size with the single) it'd be almost twice that. Surely it's not random? I'm definitely going to look this up now. Thanks for watching.
It would be nice if you'd mentioned what value throws a float into the "denormal" range you describe (when you first mention it). I also would love to see a description of precision for various values. e.g., if a 32 bit float's value is 1,000,000.0 what is the difference between this number and the next highest that can be represented in the standard?
Creel, you should not propagate the "subnormals are bad/slow" idea: Yes, there are quite a few implementations that get this wrong, but in reality any modern FPU can (and should!) handle subnormal inputs & outputs at _zero_ cycle cost and a single-digit percentage gate count increase for the FMAC unit! This is because any FPU which supports FP multiply-accumulate (which has been a part of the standard at least since the 2008 version, possibly 1998?) must be able to handle catastrophic cancellation, i.e. the FMUL part returns a 106-bit number, but then the addend (which can be of the opposite sign), can cause more than 53 of the top bits to become zero, so your normalizer have to be able to handle this situation anyway. (I was part of the 2016-2019 effort which wrote the latest (ieee754-2019) update to the standard.) BTW, in your float to decimal conversion code, the worst possible situation is a very small input (subnormal or near subnormal) which happens to be very close to the 0.5 rounding point between two decimal expansions, when this happens you might need a _lot_of digits, particularly for double or quad inputs. :-)
Can't thank you enough. GREAT video! Do you have any videos on calculating the range of possible values in IEEE 754? For example, largest representative number, smallest normalized number, largest normalized gap, etc?
Hmmmm, that's a very good question. There's plenty of resources available that show the approximate limits of floats, but I don't know how accurate they are, especially since they're usually in base 10. The Limits.h file seems to #define some very accurate limits on floats. We can make these limits with bit patterns. The largest 32 bit float will be all 1's for the exponent except the right-most bit, and the entire mantissa will be 1's: 01111111011111111111111111111111b Which is about 3.4x10^38, FLT_MAX in Limits.h. It's the same bit pattern as the signed integer 2139095039. I think the smallest non-denormal single will be all 0's for the exponent except for a 1 on the right and the mantissa will be all 0's: 00000000100000000000000000000000b This comes out to about 1.2x10^-38, it's FLT_MIN in limits.h. It's also the bit pattern for the integer 8388608. The largest denormal will be all 1's in the mantissa and an exponent of 0: 00000000011111111111111111111111b Which is much the same value as the smallest non-denormal. I don't know if it's defined in limits.h, but again we could use the integer bit pattern and force it to a float. The bit pattern for the integer is 8388607. You can force it to a float with “int i=8388607;float ff = *(float*)&i;” in C or C++, if you're in ASM, you can just write the binary. The smallest denormal will be nothing but a 1 in the right-most bit of the mantissa, the exponent is 0: 00000000000000000000000000000001b Which is about 1.4x10^-45, and again, I'm not sure if it's defined in limits, but it results from forcing the integer 1 to a float. Epsilon (is that gap?) for denormals is a 1 in the right bit, it's going to be something like 1.4x10^-45 again. Epsilon for the non-denormals changes with the exponent but I'm sure a formula would be pretty simple...? I hope this helps, and is vaguely what you were asking about, most of all I hope you have an excellent day!
At 13:24 you can see the mantissa cuts off the repeating pattern, so we could say this number can't be represented perfectly by IEEE754. So how does a programming language know to print exactly "173.7" from a float? Does it retain info about how the decimal is rounded? Or more generally, how do we convert the other way?
They round, C++ has cout.precision for instancewhich sets the number of significant digits to print to the console. This means if you set a float with “j = 3.999”and you set cout precision to 2, it will print “j” as 4. I'm not sure about the exact algorithm languages use, but I suppose they do something like the following (using 3.999 with 2 digits of precision): Multiply the number by 10 to the power of the precision (3.999*100 becomes 399.9) Add 0.5 (399.9 becomes 400.4) Divide the number by 10 to the power of the precision (4.00.4/100 becomes 4.004) Print out the whole part and a radix point (prints “4.” to the screen) Subtract the whole part (4.004-4 becomes 0.004) The next three steps would be done twice since the precision is 2: Multiply by 10 (0.004 becomes 0.04) Print out the whole part (would print out 4.0) Subtract the whole part (0.04 remains after subtracting 0) I hope this helps, and thanks for watching!
Hmm, how come the last 3 bits are different in the Matissa for numbers such as 0.8 and -2.2, they are stuck in a sequence but the last 3 bits are always different and i have no idea why
It's probably rounding. 5ths can't be represnted so 0.8 and 0.2 are going to have repeating sequences of bits. To be 100% IEEE compliant you have to set the final bits such that the error is minimized. So you'd figure out the next bit and after the mantissa's bits, if it's a 1 then add one to your mantissa, if it's a zero, then leave the mantissa how it is. At least I think that's what it is. Have a good and thanks for watching!
Great video. If I were to convert .56 would it work something like this? .56 = the exponent 2 to the negative 1 which is .50 then you divide .56 by .50 which is 1.1200000047683716 then convert to binary which would make the mantissa equate to 00011110101110000101001 after dropping the 1
32 bits are stored. Computers only work with bytes, and bytes are 8 bits each, a float is 4 bytes long. All they're doing is writing numbers like 1.110010110x2^15, or whatever. It's just scientific notation in binary. They decided that most of the useful numbers start with 1.xxxxxx, so they don't bother storing 1. It is implied. In the diagram I drew it as a bit, but it is implied by the exponent field, and it is not stored as a separate bit. Also, there are denormal numbers, these are very small values, and for denormals the implied bit is 0, instead of 1. A number is denormal if the exponent field is all 0's. So you see that the first bit of the number is implied by the exponent field, but it is never actually stored as a separate bit in RAM. I hope this helps, thanks for watching!
I think the following trick works for negative and positive? Take the log2 and always round toward -Infinity. When you take the log2 of your number, one of three things might happen: 1. The log2 is an integer, i.e. you're original number is a perfect power of 2. This log2 will be the exact exponent. 2. The log2 is a positive number with some decimals. The IEEE exponent would be the integer part of the log2. 3. The log2 is a negative number with some decimals. You must round down to the next integer, i.e. subtract 1 from the integer part of you're log. Examples: Log2(0.0137) is about -6.1897 so round it down toward -Infinity to get -7. Log2(56.89) is about 5.83 so round it down toward -Infinity to get 5 Log2(0.25) is exactly -2 so it is not rounded. Log2(256) is exactly 8 so it is not rounded. This is off the top of my head, I'm not certain it works, although I don't see why it wouldn't... Have a good one and thanks for watching!
There's an implied bit, it's always 1 unless the exponent is all 0's, then it's a 0. In the diagrams, it's the one that's raised a little. If it's not that, there's a good chance I miscounted and drew an extra bit, there should be 32 plus 1 implied bit.
Hello. Thank you for you reply. You are truly awesome and it is a great video. I did a bit of research and I gathered that. I still want to thank you sir. Wish you good health. Thanks.
***** Sounds like you've got it! The memory is 32 bits long, not 33. The implied bit is not stored in the 32 bits, it's implied by the exponent field. It's almost always a 1 for practical purposes. When reading a number we assume it starts with “1.”, i.e. one point something. This is because numbers in IEEE 754 are stored in normalized form, “1.xxx by 2 to the power of exponent”. There would be no point in including the “1.” every time since all the numbers in normalized form start this way. So it's assumed to be there and not stored in any of the number's bits. The above is only half true. On rare occasions this implied bit can be 0, and the number is not read as normalized. The only times it's 0 is when the exponent field bits are all zero. These numbers are called denormal (below or smaller than normal numbers). They are usually not encountered very often because they are so small. Some CPU's deal with denormal numbers slower than regular ones. In summary: If the exponent is something other than 0, then the number starts out with “1.xxx”, it's a normalized number and the implied bit a 1. Otherwise the number's denormal, it starts out with “0.xxx”, it's not normalized and it's tiny. Does that help?
abdelrahman tarief Morning, Test it yourself. Write a C++ program that prints out the bits of a float. If several people tell you conflicting things about IEEE standard, it is safest to check yourself. Here's some examples of what I get through my own testing: 1.0f has an exponent of 2^0 and an exponent bit pattern of 01111111 2.0f has an exponent of 2^1, and an exponent bit pattern of 10000000 129.0f has an exponent of 2^7 and an exponent bit pattern of 10000110 0.25f has an exponent of 2^-2 and an exponent bit pattern of 01111101 All of these bit patterns agree, the bias is 127. The bit pattern 10000000 is not the power 0, it is the power 1. Did I make a mistake in my video? If so, please tell me so I can add an annotation.
What's a Creel? that was really brilliant, but I tried to apply that on this video on 2:20 ruclips.net/video/I3ud8tIgHxo/видео.html the exp was good, but the presentation of fractions actually wasn't right with me ... could you please try it and tell me how could you do that? Thank's in advance.
I'd like to help, but I'm not sure what you mean. To represent a fraction in binary, you just have to keep multiplying by 2. Every time you get a 1, you record a 1, and every time you get a 0, you record a 0. For example, if you're converting 0.7 to binary: 0.7*2=1.4 So you'd record a 1, then subtract it from 1.4 to get 0.4. 0.4*2=0.8 So you'd record a 0. 0.8*2=1.6 So you'd record a 1 and subtract it from 1.6 to get 0.6. 0.6*2=1.2 So you'd record a 1 and subtract it from 1.2 to get 0.2. 0.2*2=0.4 So you'd record a 0. At that point the digits we've recorded are 10110. This means that 0.7 in binary is pretty close to 0.10110. Notice that we've encountered 0.4 again, we've seen that value before and we know the pattern of 1's and 0's it leads to. This means that if we continue to multiply in the same way, we'll get the same repeating pattern. Therefore, 0.7 in decimal is 0.101101011010110... in binary with the 10110 repeating forever. I hope that helps, thanks for watching and have a great day!
What's a Creel? thank you for your reply, what I mean is: if you checked the video on this time 2:20 you will see the presentation which I am talking about. when I try to represent the fractions of the number in that video (according to you method), I get something different from what we can see on that video (actually I tried that number on my embedded system and I get exactly like what u have explained), but what is that presentation in the video?why do we get something different from that video? could you please check it out and tell me what u get. thanks
They made two smallish mistakes in rounding. Seems strange that Texas Instruments would make an error like this. First: They round the bit pattern 1.110100001 in binary to get 1.814453 in decimal. 1.814453 multiplied by 128 is 232.249984. Then they round again! They chop their answer after the first 9, this introduces more error. I don't know what they were thinking especially since that particular bit pattern leads to a very simple number in decimal. What they should have done is this: 1.110100001 in binary is exactly 1.814453125 in decimal. Multiplying by 128 (the exponent) we get 232.25 with no rounding. Check it if you like, the number 232.25 leads to the exact bit bit pattern they have in the slides. Whereas the bit pattern for 232.249 is something more like 1.11010000011111 etc. It's close to the one in the video, but it's not the same. I might have made some mistakes also, but I hope you get the gist. Their results are close but not correct. I hope this helps, have a great day!
Thank's a lot, that is that what I wanted to know, I thought that they have made a mistake but I wasn't sure since I learned float point presentation just 5 min before watching the video :D and I thought that it can't be that I have found a mistake for TI company with 5 min of learning :D. Thank's a lot :) waiting for more of your brilliant videos. nice day, Mohammed.
Your channel is amazing, there is genuinely a lack of tutorials for people doing assembly. Thanks you saved my day.
Cheers for watching and commenting! Makes my day :)
lol I knew I would find how to do this somewhere in RUclips. I don't regret missing that class anymore
+φ First-order logic Tell me about it. :D I skipped all my Computer Systems Lectures :D
I skipped a lot because my teacher is so incompetent his explanations are the same as the book's. There's no need for him
φ First-order logic
Are we on the same course or something?
We probably fucking are xD but I had this shit last semester and already passed so unless you're going with past-me, I don't know what's going on. The theory that we have different teachers who happen to be equally lazy is too ridiculous, right?
+φ First-order logic Nah, knowing universities, this is a normal thing.
Im in a London uni if that makes our theory any more/less likely ;)
taking a systems course and this is a much better explanation than the one given in lecture. really, you're my hero.
The bias is 15 for 16 bit floats (like the GPU sometimes uses), 127 for 32 bit floats, 1023 for 64 bit doubles and 16383 for 80 bit extended precision (like our x87 FPU uses). Each of the different sized floats has it's own predefined bias.
I guess they had a choice, the exponent field gives magnitude and the mantissa gives precision, they figured an 8 bit exponent and 23 bit mantissa was a good balance between the two.
By the way, folks, the exponent is biased because it is a two's complement number, which is difficult to order from least to greatest without the offset--ordering allows for easy comparison, which simplifies CPU operations. Since the exponent in single-precision floating point format is eight bits wide, the maximum possible bit combinations it can represent is 2^8 = 256. The "complement" of an eight bit number A is the result when you subtract A from 256. Thus, the complement of 50 is 256 - 50 = 206.
To represent negative numbers, then, we can use the complement of the positive binary number. -50 in binary becomes 11001110 (which is 206 unsigned). It should be clear enough that the maximum possible complements are 128: if you begin at zero (whose complement is 256, with most significant bit ignored), you find that you exhaust them all once you arrive at 127. Thus, positive numbers range from 1 to 127, while negatives range from -1 to -128. Because 0 and 255 are reserved with special meanings, our actual number of possible exponents is 254, which range from -126 to +127. (Divide 254 by 2, giving 127. 0 and 255 are unavailable. Most negative possible value: 1 - 127 = -126. Most positive: 254 - 127 = 127.) Adding 127 to the true value results in a range of numbers from 1 to 254, which is much simpler for comparative purposes.
I had 5 minutes to understand this before my exam because I totally missed that this might be a part of it.
The float question was so easy I think I actually got it thanks to the first minutes of this video.
Thanks fam.
Very good video. You made it easy to understand how to do this by breaking it down to very simple steps.
Great tutorial Thank you! I couldn't find nothing such well explained step by step to learn how to handle this ;-)
Thank you very much for this video! I came here after studying Java and wondering how large a float/double is. After being confused by wikipedia, your video instantly helped me understand. Subscribed and will be consuming your very interesting AES encryption videos shortly!
Thanks for the video. It was the most helpful one for me on RUclips. It's so easy if you know what to do. Before that it's a struggle.
Comp Architecture class text was vague. This helped a lot. Cheers dude.
After watching 4-5 videos now I get this !!
Single-precision floating-point format is a computer number format that occupies 4 bytes (32 bits) in computer memory and represents a wide dynamic range of values by using a floating point. In IEEE 754-2008 the 32-bit base-2 format is officially referred to as binary32. It was called single in IEEE 754-1985.
Great video! This has really helped me understand, and perfectly before my exams!
Awesome video, helped me understand how to do the IEEE representation. I was so stuck on this trying to understand my professor's lecture video. You went slowly step by step, awesome job!!
There is one thing I would like to say though for the improvement. The part where you discovered that 1.35703125 is ''normalized'', I think it would be good to mention or at least make explicit that the initial ''1'' is not counted in the 23 bits. I would say that after you put that first 1, then you start counting 23 slots after that. But great job and keep up the good work!!
You are an absolute superstar. Thank you so much for this video!
For clarification, finding the power of 2 needed to normalize the value of 173.7 is done by performing - log2(173.7), and then to find the normalized value (1.35703125) perform - 173.7/log2(173.7)
or log(173.7)/log(2)
Awesome video. The first part is that u r answering the questions?? I understands it very well by looking at the questions being asked and how well explained are ur replies. Thanks for ur time . God bless u
Cheers, thanks for watching!
U well come and thanks to you. Can u help me with any good assembly language book or other material.
Are you planning to do a video on floating point arithmetic; add, subtract, multiply and maybe tougher ones like divide or square root? Would be very interesting.
Just a great video man. Thanks a lot! You make this stuff interesting for me.
Thanks, that was very clear and thorough.
Thank you, my teacher did not explain this anywhere near as well as you do.
Thank you very much for this video - nice and easy to understand.
Assuming you're talking about two IEEE f loats? You'll want to look at operations on scientific notation numbers. If the exponents are the same you can add the mantissas and normalise, don't forget the implied bit. If the exponents differ you have to multiply one of the numbers by a power of 2 till the powers are the same, then add the mantissas and normalise.
Hope this helps, thanks for watching.
Thanks a lot!! its the first time I understood this conversion :) thanks again
4:57 is in Amazing Seizure Vision otherwise helpful
Really good! Saved me quite some time. Thanks!
Thanks! Exactly what I needed for my test.
Now if you could do a tutorial on how to write a 4-function calculator in x86 ISA, I'd be in your debt haha.
Helpful, thanks ya mate
For something like the atof C++ function each version would be different depending on which headers and libraries the compiler is using.
Converting a binary int to IEEE is very easy with a few shifts.
Thanks for watching and commenting!
Hello there, nice video, but I still got one question : ) I hope I'll get an answer even if this video is a little older.
I'd like to know, if there is a system to calculate a hexadecimal representation of a (single/double) float into decimal and vice versa without determining the binary representation. Or isn't that possible, at all? ^^
Thanks in advance.
You are a godsave.
At 8:43 the exponent is supposed to be 7.. for those who are watching w/o audio
Yup, I think What's a Creel? should add an annotation there, honestly. Great video, but that bit might confuse those that aren't listening to the audio. Totally didn't think of that though while watching
倉敷市レイ Good call, I'll add the annotation!
Thanks! That was quite fast
Hey dude!! Very good c++ tutorials!! Congrats
Yeah that's my screen recorder, CamStudio, it's good but for some reason when there's not a lot of graphics in the lower portion of the screen it flashes like this. It's in the original mpeg as well. I try to make fairly busy slides to avoid it but it still happens sometimes. I hope it's not too distracting...
Big thanks, great short video too much tldr content on this dry subject. Cheers!
Thanks for a great video. Not a Part which I did not understand.
Fantastic video! Thank you.
I think I've not been clear... Once the digit 1 is recorded I subtract it from the amount we're still to explain. When I say subtract here I don't mean subtract from the bit pattern we've recorded in the mantissa, I mean from the amount we've left to describe. 0.5x2 is 1.0, we record the 1 in the mantissa then subtract it from the amount we've left to describe to get 0.0.
Hope this makes sense, thanks for watching and commenting.
Thank you! This video is very helpful.
This is a really good tutorial video, thanks a lot!
Super helpful. Thank you very much!
How rude of me. They're all basically the same system. I'm not sure how they came up with the sizes of exponent and mantissa, there seems to be no definite pattern. I guess they just went with what seemed most versatile and useful. The 64 bit for instance has an 11 bit exponent when (if it was to share the ratio of bits to exponent size with the single) it'd be almost twice that.
Surely it's not random? I'm definitely going to look this up now. Thanks for watching.
It would be nice if you'd mentioned what value throws a float into the "denormal" range you describe (when you first mention it). I also would love to see a description of precision for various values. e.g., if a 32 bit float's value is 1,000,000.0 what is the difference between this number and the next highest that can be represented in the standard?
Creel, you should not propagate the "subnormals are bad/slow" idea: Yes, there are quite a few implementations that get this wrong, but in reality any modern FPU can (and should!) handle subnormal inputs & outputs at _zero_ cycle cost and a single-digit percentage gate count increase for the FMAC unit! This is because any FPU which supports FP multiply-accumulate (which has been a part of the standard at least since the 2008 version, possibly 1998?) must be able to handle catastrophic cancellation, i.e. the FMUL part returns a 106-bit number, but then the addend (which can be of the opposite sign), can cause more than 53 of the top bits to become zero, so your normalizer have to be able to handle this situation anyway.
(I was part of the 2016-2019 effort which wrote the latest (ieee754-2019) update to the standard.)
BTW, in your float to decimal conversion code, the worst possible situation is a very small input (subnormal or near subnormal) which happens to be very close to the 0.5 rounding point between two decimal expansions, when this happens you might need a _lot_of digits, particularly for double or quad inputs. :-)
an awesome lecture sir....thank you
Can't thank you enough. GREAT video! Do you have any videos on calculating the range of possible values in IEEE 754? For example, largest representative number, smallest normalized number, largest normalized gap, etc?
Hmmmm, that's a very good question. There's plenty of resources available that show the approximate limits of floats, but I don't know how accurate they are, especially since they're usually in base 10. The Limits.h file seems to #define some very accurate limits on floats.
We can make these limits with bit patterns. The largest 32 bit float will be all 1's for the exponent except the right-most bit, and the entire mantissa will be 1's: 01111111011111111111111111111111b
Which is about 3.4x10^38, FLT_MAX in Limits.h. It's the same bit pattern as the signed integer 2139095039.
I think the smallest non-denormal single will be all 0's for the exponent except for a 1 on the right and the mantissa will be all 0's: 00000000100000000000000000000000b
This comes out to about 1.2x10^-38, it's FLT_MIN in limits.h. It's also the bit pattern for the integer 8388608.
The largest denormal will be all 1's in the mantissa and an exponent of 0: 00000000011111111111111111111111b
Which is much the same value as the smallest non-denormal. I don't know if it's defined in limits.h, but again we could use the integer bit pattern and force it to a float. The bit pattern for the integer is 8388607. You can force it to a float with “int i=8388607;float ff = *(float*)&i;” in C or C++, if you're in ASM, you can just write the binary.
The smallest denormal will be nothing but a 1 in the right-most bit of the mantissa, the exponent is 0: 00000000000000000000000000000001b
Which is about 1.4x10^-45, and again, I'm not sure if it's defined in limits, but it results from forcing the integer 1 to a float.
Epsilon (is that gap?) for denormals is a 1 in the right bit, it's going to be something like 1.4x10^-45 again. Epsilon for the non-denormals changes with the exponent but I'm sure a formula would be pretty simple...?
I hope this helps, and is vaguely what you were asking about, most of all I hope you have an excellent day!
Nice work! thank you very much
it helped a lot thanks for making this video..
Excellent!
At 13:24 you can see the mantissa cuts off the repeating pattern, so we could say this number can't be represented perfectly by IEEE754. So how does a programming language know to print exactly "173.7" from a float? Does it retain info about how the decimal is rounded?
Or more generally, how do we convert the other way?
They round, C++ has cout.precision for instancewhich sets the number of significant digits to print to the console. This means if you set a float with “j = 3.999”and you set cout precision to 2, it will print “j” as 4.
I'm not sure about the exact algorithm languages use, but I suppose they do something like the following (using 3.999 with 2 digits of precision):
Multiply the number by 10 to the power of the precision (3.999*100 becomes 399.9)
Add 0.5 (399.9 becomes 400.4)
Divide the number by 10 to the power of the precision (4.00.4/100 becomes 4.004)
Print out the whole part and a radix point (prints “4.” to the screen)
Subtract the whole part (4.004-4 becomes 0.004)
The next three steps would be done twice since the precision is 2:
Multiply by 10 (0.004 becomes 0.04)
Print out the whole part (would print out 4.0)
Subtract the whole part (0.04 remains after subtracting 0)
I hope this helps, and thanks for watching!
good video ! thanks
amazing video..but i want ask you how to find the addition of two numbers without changing them to the decimal form
fantastic. thank you so much
thanks for thso amazing video and pls post something about algorithms used in the art of computer programming .
Thank you so much..btw great accent! ;)
A Creel is "a wicker basket for carrying fish".
You're welcome ;)
Thanks but what if i have to represent it in 8bit excess.. Please help ASAP
Grade A video, I had quite a hard time understanding floats.
It's little bit confusing
the msb of Mantissa must be eliminated
173.7
Sign: 0
Exponent: 10000110
Mantissa: 01011011011001100110100
Good Video!!!
you might save me with this video ! :P
like, 1 sign bit, 4 bit for the exponent, and 8 for the mantissa
thank you, sir!
Hmm, how come the last 3 bits are different in the Matissa for numbers such as 0.8 and -2.2, they are stuck in a sequence but the last 3 bits are always different and i have no idea why
It's probably rounding. 5ths can't be represnted so 0.8 and 0.2 are going to have repeating sequences of bits. To be 100% IEEE compliant you have to set the final bits such that the error is minimized. So you'd figure out the next bit and after the mantissa's bits, if it's a 1 then add one to your mantissa, if it's a zero, then leave the mantissa how it is.
At least I think that's what it is. Have a good and thanks for watching!
Great video. If I were to convert .56 would it work something like this?
.56 = the exponent 2 to the negative 1 which is .50 then you
divide .56 by .50 which is
1.1200000047683716 then convert to binary which would make the mantissa
equate to 00011110101110000101001 after dropping the 1
Brilliant video. Do you know what algorithm most computers (assuming x86/64) use to convert decimal input to IEEE 754 FP
Thank you for the video! Is your website still active? I can't find it anywhere.
We'll look at 64 and 80 bit next tute
Was the flickering throughout or only at a particular part?
isn't the additional is always 1 on the left???
can you please reply how to write avogadro number in IEEE 754 FORMAT?
can u please explain the arithematic opertions in single precision format ?
very helpful thank you =)
Thanku
Is this actually 32 bit or 33 bit???? because I see 33 bit..
32 bits are stored. Computers only work with bytes, and bytes are 8 bits each, a float is 4 bytes long. All they're doing is writing numbers like 1.110010110x2^15, or whatever. It's just scientific notation in binary. They decided that most of the useful numbers start with 1.xxxxxx, so they don't bother storing 1. It is implied. In the diagram I drew it as a bit, but it is implied by the exponent field, and it is not stored as a separate bit. Also, there are denormal numbers, these are very small values, and for denormals the implied bit is 0, instead of 1. A number is denormal if the exponent field is all 0's. So you see that the first bit of the number is implied by the exponent field, but it is never actually stored as a separate bit in RAM. I hope this helps, thanks for watching!
How do you determine the exponent if the number is less than 1.0 using log?
I think the following trick works for negative and positive? Take the log2 and always round toward -Infinity.
When you take the log2 of your number, one of three things might happen:
1. The log2 is an integer, i.e. you're original number is a perfect power of 2. This log2 will be the exact exponent.
2. The log2 is a positive number with some decimals. The IEEE exponent would be the integer part of the log2.
3. The log2 is a negative number with some decimals. You must round down to the next integer, i.e. subtract 1 from the integer part of you're log.
Examples:
Log2(0.0137) is about -6.1897 so round it down toward -Infinity to get -7.
Log2(56.89) is about 5.83 so round it down toward -Infinity to get 5
Log2(0.25) is exactly -2 so it is not rounded.
Log2(256) is exactly 8 so it is not rounded.
This is off the top of my head, I'm not certain it works, although I don't see why it wouldn't...
Have a good one and thanks for watching!
Más claro, echale agua :p
Ironically, this video currently has 127k views lol
hoping the cows come home, but they are never coming home. lol
how to convert 0.125 into IEEE 32 Bit
Is the bias always 127 with IEEE 754? If so, is there a reason why? Thanks
because the exponent is 8 bits long, 2 ^ 8 is 256 and dividing that by 2 is 128, you subtract one and you get 127
Why is it when I count the boxes it shows as 33 bits.
There's an implied bit, it's always 1 unless the exponent is all 0's, then it's a 0. In the diagrams, it's the one that's raised a little. If it's not that, there's a good chance I miscounted and drew an extra bit, there should be 32 plus 1 implied bit.
Hello. Thank you for you reply. You are truly awesome and it is a great video. I did a bit of research and I gathered that. I still want to thank you sir. Wish you good health. Thanks.
*****
Sounds like you've got it! The memory is 32 bits long, not 33.
The implied bit is not stored in the 32 bits, it's implied by the exponent field. It's almost always a 1 for practical purposes. When reading a number we assume it starts with “1.”, i.e. one point something. This is because numbers in IEEE 754 are stored in normalized form, “1.xxx by 2 to the power of exponent”. There would be no point in including the “1.” every time since all the numbers in normalized form start this way. So it's assumed to be there and not stored in any of the number's bits.
The above is only half true. On rare occasions this implied bit can be 0, and the number is not read as normalized. The only times it's 0 is when the exponent field bits are all zero. These numbers are called denormal (below or smaller than normal numbers). They are usually not encountered very often because they are so small. Some CPU's deal with denormal numbers slower than regular ones.
In summary:
If the exponent is something other than 0, then the number starts out with “1.xxx”, it's a normalized number and the implied bit a 1.
Otherwise the number's denormal, it starts out with “0.xxx”, it's not normalized and it's tiny.
Does that help?
Sorry!! Can't speak Australian..
Ha, ha, ha!
I'm just chuffed that you know where the accent is from!
I couldn't find anything...
in the exponent part 10000000 = 0 , so 7 should equals to 10000111 not 10000110 .
Right
antonny K I found in some sites that the equation to retrieve the exponent part is Exp.-127 , so is it 127 or 128 ?
abdelrahman tarief
Morning,
Test it yourself. Write a C++ program that prints out the bits of a float. If several people tell you conflicting things about IEEE standard, it is safest to check yourself.
Here's some examples of what I get through my own testing:
1.0f has an exponent of 2^0 and an exponent bit pattern of 01111111
2.0f has an exponent of 2^1, and an exponent bit pattern of 10000000
129.0f has an exponent of 2^7 and an exponent bit pattern of 10000110
0.25f has an exponent of 2^-2 and an exponent bit pattern of 01111101
All of these bit patterns agree, the bias is 127. The bit pattern 10000000 is not the power 0, it is the power 1. Did I make a mistake in my video? If so, please tell me so I can add an annotation.
Oops, i responded too fast. You're right indeed! 10000110 = 2^7. Tricky (at least for my brain). Sorry. Btw,what you do is fantastic. Thx very much !
oh another thing. I'm forever grateful, cause i didn't know what was a creel before discovering your channel and now i know ! :D Cheers from France
Can't find your calculator, thuogh...
What's a Creel?
that was really brilliant,
but I tried to apply that on this video on 2:20
ruclips.net/video/I3ud8tIgHxo/видео.html
the exp was good, but the presentation of fractions actually wasn't right with me ... could you please try it and tell me how could you do that?
Thank's in advance.
I'd like to help, but I'm not sure what you mean. To represent a fraction in binary, you just have to keep multiplying by 2. Every time you get a 1, you record a 1, and every time you get a 0, you record a 0.
For example, if you're converting 0.7 to binary:
0.7*2=1.4 So you'd record a 1, then subtract it from 1.4 to get 0.4.
0.4*2=0.8 So you'd record a 0.
0.8*2=1.6 So you'd record a 1 and subtract it from 1.6 to get 0.6.
0.6*2=1.2 So you'd record a 1 and subtract it from 1.2 to get 0.2.
0.2*2=0.4 So you'd record a 0.
At that point the digits we've recorded are 10110. This means that 0.7 in binary is pretty close to 0.10110. Notice that we've encountered 0.4 again, we've seen that value before and we know the pattern of 1's and 0's it leads to. This means that if we continue to multiply in the same way, we'll get the same repeating pattern. Therefore, 0.7 in decimal is 0.101101011010110... in binary with the 10110 repeating forever.
I hope that helps, thanks for watching and have a great day!
What's a Creel? thank you for your reply,
what I mean is:
if you checked the video on this time 2:20
you will see the presentation which I am talking about.
when I try to represent the fractions of the number in that video (according to you method), I get something different from what we can see on that video (actually I tried that number on my embedded system and I get exactly like what u have explained), but what is that presentation in the video?why do we get something different from that video?
could you please check it out and tell me what u get.
thanks
They made two smallish mistakes in rounding. Seems strange that Texas Instruments would make an error like this.
First: They round the bit pattern 1.110100001 in binary to get 1.814453 in decimal. 1.814453 multiplied by 128 is 232.249984. Then they round again! They chop their answer after the first 9, this introduces more error. I don't know what they were thinking especially since that particular bit pattern leads to a very simple number in decimal.
What they should have done is this: 1.110100001 in binary is exactly 1.814453125 in decimal. Multiplying by 128 (the exponent) we get 232.25 with no rounding. Check it if you like, the number 232.25 leads to the exact bit bit pattern they have in the slides.
Whereas the bit pattern for 232.249 is something more like 1.11010000011111 etc. It's close to the one in the video, but it's not the same.
I might have made some mistakes also, but I hope you get the gist. Their results are close but not correct.
I hope this helps, have a great day!
Thank's a lot, that is that what I wanted to know, I thought that they have made a mistake but I wasn't sure since I learned float point presentation just 5 min before watching the video :D and I thought that it can't be that I have found a mistake for TI company with 5 min of learning :D.
Thank's a lot :) waiting for more of your brilliant videos.
nice day,
Mohammed.
it'd be nice if i didnt get a seizure at 4:55