At 08:10 AM 9/26/01 , you wrote:
>> bash$ bc -l
>> ibase=2
>> .0111001110110110010001011010000111001010110000001000001100010010
>> .4519999999999999999765812330743131042254390195012092590332031250
>>
>>As you can see, the result is not 0.452... There is no exact binary
>>representation for 0.452. As all floatingpoint values are stored as
>>fraction and an exponent, (double)452 has no exact binary representation
>>as well.
>
>
>Thank you for your response. This seems remarkable - there are values that
>connot be represented using floating point numbers, even though as decimal
>numbers they are "simple" (non-recursive, and without any fractional part
>e.g. 452). Are there any other such numbers?
>
>Matthew Fincham

Yes. A two-second SWAG tells me that any number that is not a power of two
(not of the form 2^N) could not be expressed exactly in floating point
representation, if anyone that really knows the answer would like to give
more input, I'd be happy to read. Or, I could find the time to explore the
math (sometime next decade, when I'm not so busy, or when I *have* to care
because of some assignment ;).

check out (explains why floating point numbers are called *floating*
*point*, among other things):
http://www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html

the IEEE standard is here:
http://www.psc.edu/general/software/packages/ieee/ieee.html

The standard does a better job of quickly showing why a double gives you a
more accurate number than a float (on a system where float = 32 bits,
double = 64 bits). You get more 9's, which is why the double rounded to
452.00000 and the float rounded to 451.99998. You might want to look this
over, then read the first link, then come back to the spec.

This class tutorial also looks fairly good:
http://www.scri.fsu.edu/~jac/MAD3401/Backgrnd/ieee.html

(btw, these sites were found by searching www.google.com with
floating+point+representation)



--
Timothy A. Musson
NASA's John Glenn Research Center at Lewis Field
Software Engineer
Zin Technologies
216-977-0608                It's not the size of the dog in the fight,
mussont@zin-tech.com        It's the size of the fight in the dog.