Practice FP Questions

[David L. Rager]

A student asked me for some practice FP questions. Here you go:

- 6.25

2 + 8

4/9 + 3/7

1/1023

4/9 * 3/7


(4/9) / (3/7) ; (1) convert the 3/7's and 4/9 to FP. (2) convert the
3/7's and 4/9's equivalent back to fractions. (3) Invert the 3/7's
fraction. (4) Multiply. (5) Convert that answer to FP.

2 + 8

3 * 333

3333 / 3 ; that's a division operator, not a fraction


To stress test yourselves, you can make up your own formats. If
you're still struggling with the standard format, then stick with that
at first. Feel free to send out your answers to check each other.

[Addison Denenberg]

Can someone check my answers so far? I'm using the 8-bit floating point like we have in the past.

-6.25 = 1 1001 100

2 + 8 = 0 1010 010

I'm really unsure of this one,
4/9 = 0 0101 110
3/7 = 0 0101 110
4/9 + 3/7 = 0 0110 010

1/1023 = doesn't fit in 8 bits?

I've attempted the multiplication but I don't think its right and I'm not sure if my FP values of 4/9 and 3/7 are right either.

Addison

[Matt Miller]

I got the same as you did for the first two.

I got the same values of 3/7 and 4/9 that you did, but I similarly can't swear that they're correct.  Can you explain how you did the addition of the two to arrive at 0 0110 010?

[Matt Miller]

Nevermind, I think that I figured out the addition part.

But, I got 0 0110 110.

What I did for the addition was (in base 2):
  1.110 * 2^(-2)
+ 1.110 * 2^(-2)
-------------------
 11.100 * 2^(-2) --> Normalize the sum to 1.1100 * 2^(-1).
                     Convert back to the 8-bit FP representation: 0 0110 110

Anyone see any errors with this?  I've always been pretty rough on the FP stuff, so this may not be right.

----- Original Message -----
From: "Matt Miller" <ma...@mmkrh.com>
To: "Addison Denenberg" <addison....@gmail.com>
Cc: "utexas-cs352-fall2009" <utexas-cs3...@googlegroups.com>
Sent: Wednesday, December 9, 2009 10:54:19 PM GMT -06:00 US/Canada Central
Subject: Re: Practice FP Questions

Nevermind, I think that I figured out the addition part.

But, I got 0 0110 110.

What I did for the addition was (in base 2):
  1.110 * 2^(-2)
+ 1.110 * 2^(-2)
-------------------
 11.100 * 2^(-2) --> Normalize the sum to 1.1100 * 2^(-1).
                     Convert back to the 8-bit FP representation: 0 0110 110

Anyone see any errors with this?  I've always been pretty rough on the FP stuff, so this may not be right.

[Addison Denenberg]

Oh I didn't do 1.110 + 1.110, I just did 110 + 110. Are you supposed to put the 1 before it, but only if its normalized? I know you are when you multiply so that would probably make sense, but I figured out about the 1 in front when I did the multiplication problem so I might have messed the addition up.

[Addison Denenberg]

I am pretty sure you do need the one. I've been looking at these websites

http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/addFloat.html
http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/multFloat.html

They've been really helpful if anyone is confused and they also use 8-bit floating point so it's easy to follow

[Matt Miller]

That's the same page that I was looking at.  Having the leading 1 in the calculation makes sense to me because I think you'd be losing data otherwise. 

Most of the online references that I've found on doing FP addition talk about "converting to scientific notation" to do the addition, which does seem to make it easier to conceptualize what you're working on.

[Addison Denenberg]

If anyone wants to try 1/1023 and 3 x 333 in 10-bit floating point (333 doesn't fit in 8 bits), I tried it and this is what I got:

This is how its laid out: S EEEEE MMMM
Bias = 15

1/1023 = 0 00101 000

3 = 0 10000 1000
333 = 0 10111 0101
3 x 333 = 0 11001 0000

[Sean Coyle]

I think your result for 3/7 (0 0101 110) is incorrect.

You'll need to view this as plain text for it to line up correctly:

3/7 = ~.428

0 0101 110 -> 1.110 x 2^-2 = .4375, which is > 3/7

I got 1.101 x 2^-2 (.40625) -> 0 0101 101.

Then I added:
1.110 x 2^-2
+1.101 x 2^-2
-------------
11.011 x 2^-2 -> 1.1011 x 2^-1 -> 0 0110 101

If you see any mistakes in this, please let me know.


On Dec 9, 9:23 pm, Addison Denenberg <addison.denenb...@gmail.com>
wrote:

> Can someone check my answers so far? I'm using the 8-bit floating point like
> we have in the past.
>
> -6.25 = 1 1001 100
>
> 2 + 8 = 0 1010 010
>
> I'm really unsure of this one,
> 4/9 = 0 0101 110
> 3/7 = 0 0101 110
> 4/9 + 3/7 = 0 0110 010
>
> 1/1023 = doesn't fit in 8 bits?
>
> I've attempted the multiplication but I don't think its right and I'm not
> sure if my FP values of 4/9 and 3/7 are right either.
>
> Addison
>

[Addison Denenberg]

When you convert 3/7 to binary you get 0.0110110. The reason I got 0 0101 110 is because you have to check 4 past the first 1 in order to see if you need to round. The reason its 4 is because the first 1 is the one that isnt shown, then the next three bits are the mantissa, and if the 4th bit after the invisible 1 is a 1 you will have to round and if it is a 0 then you are fine. If our number in binary was 0.0110111 then you would just round up because that means that the value after the 4th 1 is greater than 1/2. It might help to look at it like this 0.01101.11, the .11 is greater than 1/2 so you would add 1 to your mantissa to round it.

The biggest problem is with a number like this one, we have 0.01101.10. This is exactly 1/2 of the least significant bit in the mantissa so now we must use round to even. To do this, you check to see what the value is before our 2nd decimal point, so 0.01101.10. Those 3 bits equal 5, which is odd, so 101.10 can be viewed as 5.5 and you will round that to 6 which is 110 and that's how I got 0 0101 110 for 3/7.

I did my best to explain it, someone please correct me if I'm wrong but that's at least how I got what I got for 3/7. Now if I was even supposed to do that, I'm not 100% sure but I'm pretty sure you would need to round.

Addison

[David L. Rager]

> that's how I got 0 0101 110 for 3/7.

FWIW, I agree with your answer for 3/7. Though, I'm surprised that
you had to use round-to-even. Are you sure 3/7 is exactly 0.0110110?

[mdm...@cs.utexas.edu]

3/7 != 27/64 (which is the fraction that you get when you add up the fractional values with 1s in that answer, so I'm pretty sure that 3/7 =! 0.011011.

I got the same answer as Addison, but didn't have to use round-to-even.

----- Original Message -----
From: "David L. Rager" <rag...@gmail.com>
To: "Addison Denenberg" <addison....@gmail.com>
Cc: "Sean Coyle" <seanp...@mail.utexas.edu>, "utexas-cs352-fall2009" <utexas-cs3...@googlegroups.com>
Sent: Thursday, December 10, 2009 4:23:02 PM GMT -06:00 US/Canada Central
Subject: Re: Practice FP Questions

[Addison Denenberg]

I just found what 3/7 is in decimal, it's .4285714286, and did the thing where you multiply it by 2 and if there is a 1 to the left of the decimal point you write a one down and then multiply everything to the right of the decimal point by 2 again. I didn't go all the way with that number so it might be more precise if you went further, which I guess if you did you'd find some more 1s so your could eventually round up. So I guess you wouldn't have to use round-to-even, but I had to use a calculator to do it all, is there an easier way to convert the fraction to binary or at least a way to do it without a calculator?

[Matt Miller]

I actually created a new question in my head in thinking about that one...

If there were a scenario like this one:

0.10001

Where those bits are not exactly equal to the fraction in question (i.e., there are more 1s hiding out further to the right that we don't need to calculate exactly), would the bolded bit above become a 1? 

It seems like it might since the actual answer is closer to 0.1001 than 0.1000, but I'm not sure if we're supposed to round or truncate in cases where round to even doesn't come into play.

----- Original Message -----
From: mdm...@cs.utexas.edu
To: "David L. Rager" <rag...@gmail.com>

[David L. Rager]

> I didn't go all the way with that number so it
> might be more precise if you went further, which I guess if you did you'd
> find some more 1s so your could eventually round up. So I guess you wouldn't
> have to use round-to-even

Bingo!

[David L. Rager]

Yes.

You first try 2nd grade rounding. If the number is exactly
represented and you're stuck, then you employ round-to-even. If the
number's not exactly represented and you used the various techniques
I've taught over the semester, then you'll have to round up anyway,
because there's bound to be at least 1 1 somewhere down the way.

[Joshua Kerns]

You would do exactly the same thing as you would in decimal. You
start with 3/7:

3/7 * 2 = 6/7 (0)
6/7 * 2 = 12/7 (1)
5/7 * 2 = 10/7 (1)
3/7 * 2 = 6/7 (0)

Here, you can see that the pattern repeats. Therefore, 3/7 is 0.[011],
where the bracketed part repeats.

On Dec 10, 5:01 pm, Addison Denenberg <addison.denenb...@gmail.com>
wrote:

[Addison Denenberg]

So is that pretty much the only way we know how to convert a fraction to binary? Just multiply it by 2 a bunch of times and write a 1 or a 0 down?

[Eddie]

So... What was the final answer to 3/7 + 4/9??

Some of us got 0 0110 010, and some got 0 0110 110.

[David L. Rager]

I get:

0 0110 110

[Addison Denenberg]

Because the smallest numbers you can represent are denormalized numbers and those have an exponent of E = 1 - bias so in this case -6 and the exponent field in FP is written as all 0s. If you look on page 86 in the table, it gives the smallest possible value for 8-bit FP as 1/512.

Sorry I can't give a better explanation than that, I've done so much FP that when I go back and look at things I have already done I get confused haha.

On Thu, Dec 10, 2009 at 10:11 PM, Michael Massaro <mikestud...@hotmail.com> wrote:

why can't you represent 1/1023 in 8 bit fp?
1/1023 = .0000000001 that's 1.0 x 2^-10
Since we can only represent numbers as low as 1.0 x 2^-7 with a 4 bit exponent, we change it to 0.001 x 2 ^-7
This as FP would be 0 0000 001
Am I wrong?

---

Windows LiveT Hotmail is faster and more secure than ever. Learn more.

[mdm...@cs.utexas.edu]

Yeah, I think you're right about that.  It can't be represented as a normalized FP number.

[Anh]

Can anyone post the answers they got to the practice FP questions that
David posted so that I can check them with my own? Or if at all
possible, David could you please post the answers?

[John Barry]

I wonder if 1 / 1023 might round up to 1 / 512, and therefore be represented by the smallest possible denormalized number... 1 / 1024 would definitely round to even and become 0, but 1 / 1023 is a little bigger.

[HM]

im a little confused as to how get the exponent for denormal numbers.
Say you have 3/511, thats
.000000011000
where do we take the decimal point to?

On Dec 10, 11:09 pm, John Barry <jb3...@gmail.com> wrote:
> I wonder if 1 / 1023 might round up to 1 / 512, and therefore be represented
> by the smallest possible denormalized number... 1 / 1024 would definitely
> round to even and become 0, but 1 / 1023 is a little bigger.
>
>
>
> On Thu, Dec 10, 2009 at 10:35 PM, <mdm...@cs.utexas.edu> wrote:
> > Yeah, I think you're right about that.  It can't be represented as a
> > normalized FP number.
>
> > ----- Original Message -----
> > From: "Michael Massaro" <mikestud1mass...@hotmail.com>
> > To: "addison denenberg" <addison.denenb...@gmail.com>,
> > mdm...@cs.utexas.edu
> > Cc: utexas-cs3...@googlegroups.com
> > Sent: Thursday, December 10, 2009 10:11:52 PM GMT -06:00 US/Canada Central
> > Subject: RE: Practice FP Questions
>
> > why can't you represent 1/1023 in 8 bit fp?
> > 1/1023 = .0000000001 that's 1.0 x 2^-10
> > Since we can only represent numbers as low as 1.0 x 2^-7 with a 4 bit
> > exponent, we change it to 0.001 x 2 ^-7
> > This as FP would be 0 0000 001
> > Am I wrong?
>

> > ------------------------------
> > Windows LiveT Hotmail is faster and more secure than ever. Learn more.<http://www.microsoft.com/windows/windowslive/hotmail_bl1/hotmail_bl1....>

[Matt Miller]

If the exponent is -7, then when you add the bias in, you get 0. Denormalized numbers always have their exponent field as all zeros. If you need -8, you're out of luck.

[Addison Denenberg]

If you get a floating point number where the exponent ends up being -7, you will write the mantissa as if the exponent is -6 and if you write the number in scientific notation you will also write 2^-6, but when you write out the floating point number you will write 0s for all the bits in the exponent field. So really, you wont ever have -7 as an exponent, and the reason that it is -6, is because you do E = 1 - bias instead of the normal way to get the value of E.

[Daniel Kuang]

0 0101 101 = 0.40625
0 0101 110 = 0.4375
0 0101 111 = 0.46875

3/7 ~= 0.428571429

3/7 != 0 0101 110 ( = 0.4375)