Problem with IEEE conversion

[Hip]

Hey guys

 

I converted 0.125 from decimal to IEEE.

The calculators result is correct but I don't get why the 0 is in front of 1111100 for the exponent.

 

Take a look at step (6).

 

This is the calculator:

http://binary-system.base-conversion.ro/real-number-converted-from-decimal-system-to-32bit-single-precision-IEEE754-binary-floating-point.php?decimal_number_base_ten=0.125&sign=0&exponent=01111100&mantissa=00000000000000000000000

[KarathKasun]

Because 8 bit.  Nothing uses 7 bit binary.

[Hip]

8 minutes ago, KarathKasun said:

Because 8 bit.  Nothing uses 7 bit binary.

Yes, but why do I set the 0 in front and not at the end like this: 11111000 ?

[KarathKasun]

2 minutes ago, Hip said:

Yes, but why do I set the 0 in front and not at the end like this: 11111000 ?

Because that would shift the entire number up by a factor of 2, just like adding a zero to 1 like 10 makes it 10 (ten) and not 1(one).

[Hip]

Just now, KarathKasun said:

Because that would shift the entire number up by a factor of 2, just like adding a zero to 1 like 10 makes it 10 and not 1.

I have this result, like on the website, so I start counting from the bottom and there is no 0 at the beginning. 

 

• 124 ÷ 2 = 62 + 0;
• 62 ÷ 2 = 31 + 0;
• 31 ÷ 2 = 15 + 1;
• 15 ÷ 2 = 7 + 1;
• 7 ÷ 2 = 3 + 1;
• 3 ÷ 2 = 1 + 1;
• 1 ÷ 2 = 0 + 1;

[KarathKasun]

9 minutes ago, Hip said:

I have this result, like on the website, so I start counting from the bottom and there is no 0 at the beginning. 

 

• 124 ÷ 2 = 62 + 0;
• 62 ÷ 2 = 31 + 0;
• 31 ÷ 2 = 15 + 1;
• 15 ÷ 2 = 7 + 1;
• 7 ÷ 2 = 3 + 1;
• 3 ÷ 2 = 1 + 1;
• 1 ÷ 2 = 0 + 1;

You always pad to the left of the number.

 

0000001 = 1

00000010 = 2

00000001 = 1

[Hip]

2 minutes ago, KarathKasun said:

You always pad to the left of the number.

 

 

When would I have to put a 1 in front of it?

 

[KarathKasun]

4 minutes ago, Hip said:

When would I have to put a 1 in front of it?

 

When its 128 to 255.

 

0(128) 0(64) 0(32) 0(16) 0(8) 0(4) 0(2) 0(1)

1111 1111 = 255

0111 1111 = 127

0011 1111 = 63

0001 1111 = 31

0000 1111 = 15

0000 0111 = 7

0000 0011 = 3

0000 0001 = 1

 

I got my 1 and 2 place mixed up in first example I gave, its fixed now.

[Hip]

1 minute ago, KarathKasun said:

When its 128 to 255.

Ah ok!

Can you tell me why the Mantissa is in this case only zeros?

I thought I would have to put it first to 001 and then fill the rest with 0000...00. Because the first number was 0,001.

[KarathKasun]

3 minutes ago, Hip said:

Ah ok!

Can you tell me why the Mantissa is in this case only zeros?

I thought I would have to put it first to 001 and then fill the rest with 0000...00. Because the first number was 0,001.

You have to pad it out to 8, 16, 32, 64, 128, ... bits total.  Mainly because this is how machines work internally.

[Hip]

3 minutes ago, KarathKasun said:

You have to pad it out to 8, 16, 32, 64, 128, ... bits total.  Mainly because this is how machines work internally.

But why not start with 001 as I usually do when I have numbers like 101, then I have 1,01*2^2 and later set ,01 as the first numbers of the Mantissa 0100000..00. 

[KarathKasun]

2 minutes ago, Hip said:

But why not start with 001 as I usually do when I have numbers like 101, then I have 1,01*2^2 and later set ,01 as the first numbers of the Mantissa 0100000..00. 

Because that is no longer the same number.

 

Always pad to the left.

 

That like asking why I cant write 131 as 131,000 to fit into a 6 digit field on a form.  Do that on your taxes, see how well it works.

[Hip]

4 minutes ago, KarathKasun said:

Because that is no longer the same number.

So it it possible that when I always have numbers like 0.125 or so I have to fill up with zeros at the end because it always ends up like 001 so it has no number in front ot the ","?

[KarathKasun]

23 minutes ago, Hip said:

So it it possible that when I always have numbers like 0.125 or so I have to fill up with zeros at the end because it always ends up like 001 so it has no number in front ot the ","?

 

Yes.

 

You do not get a 1 at the eighth bit of the exponent until you hit 2 in decimal.

The exponent must ALWAYS be 8 characters/bits long.

The mantissa is what describes the right of the decimal point, which in IEEE 754 ends up being numbers that can not be described by the exponent alone.

[KarathKasun]

Really, you should walk through numbers and look at the patterns that emerge from the conversion until you understand what is going on.

 

Ive not had to do IEEE 754 for anything, and its representation format is a bit confusing at first.

 

Sign field is always 1 bit, exponent is 8 bits, mantissa is always 23 bits.  Exponent is padded to the left, mantissa is padded to the right (or truncated from the right).

 

In short, you always pad "away" from the decimal.  Just like with base 10.

[straight_stewie]

1 hour ago, Hip said:

Yes, but why do I set the 0 in front and not at the end like this: 11111000 ?

Using base 10 numbers:

 

For the same reason that 0756 is equivalent to 756, but not equivalent to 7560.

A floating point example in base 10:

For the same reason that 0734.560 is equivalent to 734.56 but not 7340.056

[Mira Yurizaki]

Padding is just a formality to show you how it's actually represented in the computer. Though in the case of the mantissa, you need to have left padding until you get to the first 1 because you need to know where it starts since it represents a fractional value. Similarly why you need to right pad 0s for integers.

 

However, if you're just writing this down to explain what's going on, you don't need to pad more than necessary. i.e., If the mantissa is 001, you don't need to right pad it out to say 00100000000000000000000 if you're explaining how the system works to someone. If you're explaining how it's represented in a computer, then yes, you do need to pad it out.

 

Also note that the number of bits assigned to the exponent and mantissa changes depending on the number of bits the floating point number in total is. 8-bit exponent and 23-bit* mantissas are only a thing in 32-bit IEEE 754 numbers.

 

*Technically it's 24-bits, but the bit that represents 2^0 is always 1 due to mantissa normalization. So it's always implied to be there.

 

EDIT: It might be prudent to also right pad the number with 0s to a certain amount to explain floating point rounding issues. But if explaining just how the floating point system works, I don't think it's necessary.

[wasab]

We pad cuz it is 8 bits that represents the exponent. If you are short of 8 bits, just add zeros as placeholder. You need to pad left with 0s because that doesn't change the values.

 

So x xxxxxxxx xxxxxxxxxxxxxxxxxxxxx the 2nd group of x is your expoenet. 

 

If after normalizing, your expoent is 3 for example then binary is 011 but you can't do

x 011 xxxxxxxxxxxxxxxxxxxxx now can you? Computer is not going to read that. IEEE altogther consists of 32 bits so you pad. 

 

If you pad right then the binary becomes 

01100000, what does that equal in decimal? It is 96, which is not 3. 

 

How about pad left to 00000011? What does that equal in decimal? It equals 3. 

 

 

 

 

[Mira Yurizaki]

I should clear up in my last post, it's extra padding that's a formality. So the mantissa needs to be left padded, but right padding is extra. Likewise the exponent needs to be right padded, but left padding is extra.

[Hip]

3 hours ago, straight_stewie said:

Using base 10 numbers:

 

For the same reason that 0756 is equivalent to 756, but not equivalent to 7560.

A floating point example in base 10:

For the same reason that 0734.560 is equivalent to 734.56 but not 7340.056

That made click in my head! Thanks for that sentences  

[Hip]

3 hours ago, Mira Yurizaki said:

 

However, if you're just writing this down to explain what's going on, you don't need to pad more than necessary. i.e., If the mantissa is 001, you don't need to right pad it out to say 00100000000000000000000 if you're explaining how the system works to someone. If you're explaining how it's represented in a computer, then yes, you do need to pad it out.

 

But why is the Mantissa in this case of 001, only zeros?

I thought it is 0010000000..00

[KarathKasun]

Just now, Hip said:

But why is the Mantissa in this case of 001, only zeros?

I thought it is 0010000000..00

The mantissa is the portion of the number to the right of the decimal point.  For the 754 standard, it needs to be 23 bits, so a mantissa of 1 001 becomes 00100000000000000000000 because the first digit is dropped and it is padded to the right to 23 places.

[Hip]

1 minute ago, KarathKasun said:

The mantissa is the portion of the number to the right of the decimal point.  For the 754 standard, it needs to be 23 bits, so a mantissa of 1 001 becomes 00100000000000000000000 because the first digit is dropped and it is padded to the right to 23 places.

But please check the website I have quoted in the original post. It says Mantissa is only zeros. I wonder why that? I have the same result in other files but I still don't understand why Mantissa is only zeros at this point.

[Mira Yurizaki]

2 minutes ago, Hip said:

But why is the Mantissa in this case of 001, only zeros?

I thought it is 0010000000..00

Is this value normalized or no? If it's not normalized, then floating point formats will normalize it so the 1 is left of the decimal (binary?) point. It's then excluded from being encoded in the data because normalizing always means that the bit to represent 2^0 is 1.

 

If it helps, let's use decimal. Say we have a mantissa of 0.001234. Normalizing it brings it to 1.234. If we have a binary number of 0.00101, then normalizing it brings it to 1.01.

[Hip]

24 minutes ago, Mira Yurizaki said:

Is this value normalized or no? If it's not normalized, then floating point formats will normalize it so the 1 is left of the decimal (binary?) point. It's then excluded from being encoded in the data because normalizing always means that the bit to represent 2^0 is 1.

 

If it helps, let's use decimal. Say we have a mantissa of 0.001234. Normalizing it brings it to 1.234. If we have a binary number of 0.00101, then normalizing it brings it to 1.01.

Exactly, so after normalizing I have 1,000*2^-3 here. So I just take the numbers behind the "," after normalizing and put it into the Mantissa, right?