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.

Here's more info:

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