4 ms·

Hi acqq, I did type 123 into that float converter and the numbers I got back are what I posted. I'm not sure how we're getting different FP reps for the same nu

Hi acqq, I did type 123 into that float converter and the numbers I got back are what I posted. I'm not sure how we're getting different FP reps for the same number. I simply typed 123 into the decimal representation box. If I'm missing something please let me know.

andrewcooke 14y ago
the problem is that for 0.123 (say) it's not 123 multiplied by 0.001 - the multiplier has to be a power of 2, so the thing being multiplied is no longer a simple integer. see my answer at http://stackoverflow.com/a/7289400/181772 http://stackoverflow.com/a/7289400/181772 for a similar case.
acqq 14y ago
Read carefully. 123 is represented 100% exactly, bit for bit. Look at the bits in the mantissa, 111011, leading 1 is the implicit and it matches >>> bin( 123 ) '0b1111011' not at the "interpretation for humans" which shows 1.921875. All integers up to some very big one are represented exactly in IEEE base-2 FP (or you can say that the fractions that are the result from the storage of the integers have a finite binary representation, but then you make harder for you to have an easy insight). Disclaimer: I have similar experiences to smoyer, in the eighties of the previous century I've implemented a reasonable chunk of IEEE 754 in x86 assembly.
- MikeDucker 14y ago
  I see what you're saying, but if you take the 111011 as representing 1/2 1/4 1/8 etc. then it does equal 0.921875. I'm presuming that this value is added onto 1 (fiddling with the tick boxes confirms this) to be used as the mantissa. I'm not doubting what you know about floating points, but I think that this calculator is still trying to say (whether that be right or wrong based on IEEE) 6 ^ 1.921875
  - acqq 14y ago
    You didn't get the different FP representation, what's important are the bits, they are what they are, not how you decide to translate them to the decimal system. The only thing being processed are the bits. Concentrating on the decimal interpretation (which is just that, the number is processed as the base 2 IEEE 754 FP) you missed that 123 has an absolutely exact binary representation.
  - Tuna-Fish 14y ago
    Well, it is, but it's still exact. Think of it a while, in base-10 (if it makes it easier for you). Let's say you save numbers in format a * 10^b. B has enough range to not to be a problem, but a can only hold 3 digits. What integers can you represent exactly? 1 = 1.00 * 10^0. 2 = 2.00 * 10^1, trough to 999 = 9.99*10^2. Or in other words, so long as mantissa has less bits than the number you are converting, it can be represented perfectly in floating point. So, 4 is always 4, not some number very close to 4. If it ends up as something else, you're the one who has messed it up.
RickRegan 14y ago
0.921875 is 921875/10^6 = 59/64, which is exactly representable in binary since 64 (2^6) is a power of two. So 1.921875 * 2^6 = 1 59/64 * 64 = 64 + 59 = 123. Or as acqq pointed out, the bit representations are the same: 1.921875 = 1.111011 (using my converter at http://www.exploringbinary.com/binary-converter/ http://www.exploringbinary.com/binary-converter/ ), which is 123 (1111011) shifted right 6 bits.

andrewcooke 14y ago

the problem is that for 0.123 (say) it's not 123 multiplied by 0.001 - the multiplier has to be a power of 2, so the thing being multiplied is no longer a simple integer. see my answer at http://stackoverflow.com/a/7289400/181772 http://stackoverflow.com/a/7289400/181772 for a similar case.

acqq 14y ago

Read carefully. 123 is represented 100% exactly, bit for bit. Look at the bits in the mantissa, 111011, leading 1 is the implicit and it matches >>> bin( 123 ) '0b1111011' not at the "interpretation for humans" which shows 1.921875. All integers up to some very big one are represented exactly in IEEE base-2 FP (or you can say that the fractions that are the result from the storage of the integers have a finite binary representation, but then you make harder for you to have an easy insight). Disclaimer: I have similar experiences to smoyer, in the eighties of the previous century I've implemented a reasonable chunk of IEEE 754 in x86 assembly.

MikeDucker 14y ago
I see what you're saying, but if you take the 111011 as representing 1/2 1/4 1/8 etc. then it does equal 0.921875. I'm presuming that this value is added onto 1 (fiddling with the tick boxes confirms this) to be used as the mantissa. I'm not doubting what you know about floating points, but I think that this calculator is still trying to say (whether that be right or wrong based on IEEE) 6 ^ 1.921875
- acqq 14y ago
  You didn't get the different FP representation, what's important are the bits, they are what they are, not how you decide to translate them to the decimal system. The only thing being processed are the bits. Concentrating on the decimal interpretation (which is just that, the number is processed as the base 2 IEEE 754 FP) you missed that 123 has an absolutely exact binary representation.
- Tuna-Fish 14y ago
  Well, it is, but it's still exact. Think of it a while, in base-10 (if it makes it easier for you). Let's say you save numbers in format a * 10^b. B has enough range to not to be a problem, but a can only hold 3 digits. What integers can you represent exactly? 1 = 1.00 * 10^0. 2 = 2.00 * 10^1, trough to 999 = 9.99*10^2. Or in other words, so long as mantissa has less bits than the number you are converting, it can be represented perfectly in floating point. So, 4 is always 4, not some number very close to 4. If it ends up as something else, you're the one who has messed it up.

RickRegan 14y ago

0.921875 is 921875/10^6 = 59/64, which is exactly representable in binary since 64 (2^6) is a power of two. So 1.921875 * 2^6 = 1 59/64 * 64 = 64 + 59 = 123. Or as acqq pointed out, the bit representations are the same: 1.921875 = 1.111011 (using my converter at http://www.exploringbinary.com/binary-converter/ http://www.exploringbinary.com/binary-converter/ ), which is 123 (1111011) shifted right 6 bits.