Need Help on Fixing Int2Float Serialization Function

I have this project in which requires that an integer value be safeley converted into a floating point value by preserving its bitmask. While Strife Onizuka's Float <--> integer library does work, I have found that his Integer --> Float function will not work for some of the values that are given to it. I have thus decided if I could have written a perhaps less elegant, but fully functional solution to suppliment his float --> integer solution. But I am at a loss here...

float Int2Float(integer intInput){

	integer intSign = intInput >> 31; //Get only the first digit
	integer intExponent = (intInput & 2139095040) >> 23; // get only a certain 8 digits
	integer intFractionBinary = intInput & 8388607; //Get only the last 23 digits
	float fltFraction = 1.0;

	integer intIndex = 23;
	integer intDigit = 0;
	for(;intIndex>0;intIndex--){

		intDigit = (intInput >> (intIndex - 1))	% 2;
		fltFraction += (llPow(2.0, (float) (intIndex - 24) ) * (float)intDigit);
		
	}
	return (llPow(-1.0,(float) intSign) * llPow(2.0 , (float) ( intExponent - 127)) * fltFraction);

}

I have looked closely at wikipedia on the 32 bit IEEE 754 float standard.

Supposedly, a 32 bit floating point number can be derived from the formula...

float = -1^intSign * 2^(intExponent - 127) * 1.fraction

I believe I have captured all the bits correctly. Bit #31 for the sign, bits #30-23 for the exponent, and bits #22-0 for the fraction.

Could it be that I am improperly handling the use of the fractional part of my float. I do seem to be having difficulty understanding putting intFractionBinary as 1.fraction as described by that source of information.

Here is the page I am talking about if you are interested...
http://en.wikipedia.org/wiki/IEEE_754

thank you for your time. I really do hope I can figure it out. This is for a really important project I can see others making use of.

~Tenk

Are these, by any chance, integer values with all 1's in what will become the exponent block? Such float values are interpreted as +/- infinity or NaN (not a number). Therefore it will be impossible to encode as a float any integer values in the ranges 0x7f800000-0x7fffffff and 0xff800000-0xffffffff.


Not necessarily. If the exponent block value is 0, then the float value is "denormalised", i.e., the fraction is not assumed to have a 1 before the decimal point.

IIRC floating point representations with a zero exponent field and non-zero mantissa field are...EDIT: Nevermin. See Deanna Trollop's post.

Ah. That was it. I was misremembering special exponent values. Heh.

ooh, that is interesting... I haven't thought about floats having infinity and NAN values. Also, I didn't consider why there was a 1.fraction. So there is a rule to this part of the formula. So I take it that if the exponent is != 0, it is safe to use 1.fraction, otherwise, if exponent == 0, I will have to use 0.fraction?

I really didn't get that out of the wiki. Thank you and I'll see what happens from there.

This effectively expands the 23-bit fractional block to 24 bits, since a "1" bit is assumed to precede it in all but the denormalized case. The value of 0.0 would be impossible to represent if all values were forced to contain a 1 somewhere.


Essentially, yes.


See the "Notes" section under "Singe-precision 32-bit."