Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Floating point variables  RSS feed

 
Gabriel White
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there, I have this program that I am supposed to write but I have restrictions as listed here:

Write a program that takes a hexadecimal number which it interprets to be a IEEE single precision floating point value and prints it out as 2 to the exponent times the sum of powers of 2. The input value should be a command line parameter. Use of the program should look like this:

C:\> java floatPTest 3e900000

3e900000 ==> 2^-2(1 + 2^-3)

Use only integer (bitwise and shift) operations. Do not use floating point variables in any of the intermediate steps. Do not use Strings where you can avoid it. Avoid arrays. Avoid Math.pow(...).

So no arrays, no using Float.intBitsToFloat(x) when int x= 0x3e900000, no strings for the lengths for the bit arrays.

I really need a push in the right direction on this one. I know how to do the math on this one, but I guess I am a little shakey on how to implement shift and bitwise operands to find the double that I will use to find the precision floating point value.

I have implemented this code, but it is nowhere near the output that I need because I need to be able to shift through the mantissa to find the next bit and covert it to a power of 2 (or do I?)and I also used the floating point variables like I wasn't supposed to.

Any ideas would be great
Thanks
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gabriel White:
... I have implemented this code, but it is nowhere near the output that I need...

As a general approach, I recommend carefully describing each of your steps in English before trying to code it in Java. Use this to work through the given example (0x3e900000), and confirm that your steps generate the correct output. This should help identify logic problems. Once you've done this, then you can work on translating the English descriptions to Java statements.

Note: The assignment seems to ask for a single precision floating-point value, but your code looks like it's treating it as a double-precision (with the 52 mantissa bits and an exponent bias of 1023). Or am I missing something?

Also, do you need to be concerned with the sign bit? Or whether the value is normalized?
[ January 17, 2007: Message edited by: marc weber ]
 
Gabriel White
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marc and thanks for the reply. Is there a way to do single floating precision? I just found this as an example as how to find the exponent. I guess my question is how do I write the code to shift in order to go through the binary representation of this number which is:

3e900000 = 00111110100100000000000000000000

0 represents the sign (so positive) 01111101 represents the exponent = 127 -127 =-2 so knowing that the mantissa has bits in it then we know that it is also part of the decimal notation of 2^-3, so in all this is the result of 2^-2 * (1 + 2^-3) (normalized from 0.28125 which is the Float of the int hex. This is why I used a double here to represent the value of the bits. The offset is used because of the 64 bit shift.

Is there another way of doing this? For example, can I just use 2* 1 + exponent ^-23 ?

As you can see, I can do the math, it is just the shifting that I am having trouble with. I have never performed ANY bitwise or shifting operations before this. This is an obvious program to complete using an array and using math.pow, but as placed in the restrictions I am not allowed to do so.

Thanks again.
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gabriel White:
Is there a way to do single floating precision? I just found this as an example as how to find the exponent...

You're starting with 32 bits (an int), and you want to keep this as 32 bits (because it's single-precision), so there's no purpose in trying to juggle 64 bits. I think the example you found is making this more complicated than it needs to be.

To illustrate one approach, you can find the sign bit simply by shifting to the right by 31. This would isolate the sign bit by putting it at the far right. This assumes that when the sign bit is shifted to the right, the bits introduced to the left will be zeros, so you need to use the unsigned right shift. (In Java, there is a signed right shift and an unsigned right shift. Make sure you understand the differences.)

This approach can be expanded on to isolate the exponent and mantissa. Keep in mind that if you shift bits out of range, they are "lost." You can make use of this.
 
Gabriel White
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, I finally figured this one out but there are still a few kinks.

I need to finalize my Mantissa in 2's power form. So if after shifting I am left with the fraction of the hex number in floating point and it looks something like this: 11001001, then the 2's power of that would be (since it is the Mantissa all of the exponents are neg) 2^-1 + 2^-2 + 2^-5 + 2^-8.

When I try to mask by 0x1 and shift to the left I get the number that is actually there at that position rather than what I need (above).

Here is my code so far. There are a few erroneous SOP lines in there for testing, but it is pretty straight forward.

Thanks in advance.

 
Gabriel White
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anything?
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look at it this way: You have 23 bits. You want to check each one of these (loop through them) to see if it's a 0 or 1 (probably by applying a mask). If it's a 1, then you produce output (" + 2^-...).

(Note that the mask can be shifted with each iteration, and the index of the iteration can correspond to the power of 2 that's being checked.)

A couple of other things to look at...

Are you sure you want to shift this to the right by the number of trailing zeros? (I think you're assuming that all the trailing zeros were all inserted by x << 9, but this might not be the case.)

If you have a sign bit of 1, won't this show up in your exponent?
[ January 24, 2007: Message edited by: marc weber ]
 
Scott Mutter
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is my code so far.


The way you went about doing this involves much unnecessary code. Here is the very best solution:
(Yes, I wrote this myself!!)



[ April 09, 2007: Message edited by: Scott Mutter ]
[ April 09, 2007: Message edited by: John Whitehorse ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!