FP to FP Binary/Hex
Author Message
FP to FP Binary/Hex

I've noticed that all functions that convert a floating-point number to
binary or hexadecimal convert it to an integer first.  I created a
program in QBasic to print the bytes of a floating-point number in hex
to figure out the format of these numbers, and since the mantissa seem
to be binary, I'd think it'd be easy to convert to floating-point
hexadecimal.  Which program, if any, does this?

Wed, 25 Sep 2002 03:00:00 GMT
FP to FP Binary/Hex

Quote:

> I've noticed that all functions that convert a floating-point number to
> binary or hexadecimal convert it to an integer first.  I created a
> program in QBasic to print the bytes of a floating-point number in hex
> to figure out the format of these numbers, and since the mantissa seem
> to be binary, I'd think it'd be easy to convert to floating-point
> hexadecimal.  Which program, if any, does this?

You don't need any special program. All you need is a code snippet that can
read a byte from memory and print it out as two hexadecimal digits. Repeat 4
times for single-precision, 8 times for double-precision and 10 times for
extended precision.

For input, you need a code snippet that can read two hexadecimal digits and
place it into a memory byte. Repeat as above for the various floating-point
types. Note that not every hexadecimal value of the appropriate length is a
valid number; some are NANs etc.

Daniel Pfeffer

Thu, 26 Sep 2002 03:00:00 GMT
FP to FP Binary/Hex

Quote:

> I've noticed that all functions that convert a floating-point number to
> binary or hexadecimal convert it to an integer first.  I created a
> program in QBasic to print the bytes of a floating-point number in hex
> to figure out the format of these numbers, and since the mantissa seem
> to be binary, I'd think it'd be easy to convert to floating-point
> hexadecimal.  Which program, if any, does this?

Yeah man, it's /all/ binary.

I just posted a cool 1.01 on FP. Here it is again. Check it out:

Floating-point math 1.01 (well, actually ~1.0999999046326)
----------------------------------------------------------
A hypothetical computer might encode 1.54 as:

S Exponent  Imp Mantissa (=0x451EB8)
0 0111 1111 [1].100 0101 0001 1110 1011 1000
^ ^^^^^^^^^  ^    \ fractional part of n (m/0x800000)
|     |      |__ implied integer 1(one).
|     \_ 127-biased exponent (2^x-bias)
\___ mantissa sign bit (0=+, 1=-)

Meaning:
([1] + 0x451EB8/0x800000) * 2^(127-127)
([1] + 4529848/8388608) * 2^0
which is approx 1.5399999961853
The implied 1 represents 1 and the least significant mantissa bit represents
2^-23,or around 0.000000119209289551.

So, that is the nearest representation of 1.54 a 4-byte float in that format
can give you.

BTW: Double your 1.54 and you only the exponent is incremented.
n     + Imp Mantissa                     Exponent
3.08 = 0 [1].100 0101 0001 1110 1011 1000 1000 0000

Meaning:
(1 + 0x451EB8/0x800000) * 2^(128-127)
(1 + 4529848/8388608) * 2^1
which is around 3.079999923706
Now the implied 1 represents 2 and the least significant mantissa bit
represents
2^-22,or around 0.000000238418579102.

This is normal?
---------------
Also, note that typically the [1], I labeled as implied, is not stored.
That's because of _normalization_. Think of it like this: If you always used
scientific notation, you'd never normally write 0.1543E+1. You'd normalize
it to be 1.543E+0. That being the case, 0 should never appear as the first
digit (unless the whole {*filter*}y value is zero). Now think binary; if the
first digit isn't going to be zero... it has to be one! The caveat is the
value zero -- it is a special case and is usually defined as all four bytes
equaling zero, which actually translates to 1 * 2^-127 (about 5.877E-39)
because of the implied 1. Note that you could have a negative "zero" by
flipping the sign bit.

Exercise: So, what would be the maximum value?

BTW: What I described is basically a simplified form of IEEE 754... /the/ FP
spec.

http://www.*-*-*.com/ ~hollasch/cgindex/coding/ieeefloat....

And you thought all you had to worry about was that old Pentium math bug? ;)

------------------------------------

Yeah, it wouldn't be hard to print, say 65535.25 as FFFF.4 or even as
F.FFF4E+3

Other notes:
* When the exponent becomes 0 (ie. -127) the implied [1] goes away, which
allows zero to be represented perfectly, and allows for smaller numbers at
the expense of accuracy of them.
* FP numbers, like all the other Intel stuff, is stored little-endian...
which looks backwards.

--
-LZ

Thu, 26 Sep 2002 03:00:00 GMT
FP to FP Binary/Hex

Try this out:

DEFINT A-Z

r! = 3.14159265359#
r\$ = MKS\$(r!)

sr = ASC(MID\$(r\$, 4, 1)) \ 128
xr = ASC(MID\$(r\$, 4, 1)) AND 127
xr = xr * 2 + ASC(MID\$(r\$, 3, 1)) \ 128
mr& = 128: IF xr = 0 THEN mr& = 0
mr& = mr& + (ASC(MID\$(r\$, 3, 1)) AND 127)
mr& = mr& * 256& + ASC(MID\$(r\$, 2, 1))
mr& = mr& * 256& + ASC(MID\$(r\$, 1, 1))
WHILE (xr MOD 4) <> 2
mr& = mr& * 2
xr = xr - 1
WEND
xr = xr - 127 + 1
IF (mr& \ 16777216) = 0 THEN
mr& = mr& * 16
xr = xr - 4
END IF
PRINT
IF sr THEN PRINT "-";
FOR i = 1 TO 10
IF i = 2 THEN PRINT ".";
PRINT HEX\$(mr& \ 16777216);
mr& = mr& MOD 16777216
IF mr& = 0 THEN EXIT FOR
mr& = mr& * 16
NEXT i
IF xr < 0 THEN
PRINT "e-"; HEX\$(-xr \ 4);
ELSEIF xr > 0 THEN
PRINT "e+"; HEX\$(xr \ 4);
END IF

--
-LZ

Thu, 26 Sep 2002 03:00:00 GMT

 Page 1 of 1 [ 4 post ]

Relevant Pages