Still puzzled by floats

leriksen has asked for the wisdom of the Perl Monks concerning the following question:

This question flows from an earlier problem I asked about summing to zero. Thanks for the replies.

Reading the perl FAQ, they state

However, 19.95 can't be precisely represented as a binary floating point number,...,

Why not? Surely there is a bit pattern in the IEEE float format that precisely represents 19.95 (1.995E1). If a float is stored in,say, 32 bits on a particulat platfrom, some bits are for the mantissa and some are for the exponent and sign. If 24 bits store the mantissa, isn't there a bit pattern from those 24 bits that precisely represents 1.995 ? Its not like it's a lot of precision.

If that is so, why can't the conversion library get that bit exact. The machine can represent 0.15 to however many decimal places it stores, why can't the conversion library create the correct representation? I understand that _expressions_ will potentially have inaccuracies, like exp(ln(x)) resulting in something very close but not quite x. But a string literal should (in my utopian view) convert precisely. The only exception to this would be a string literal expressing a value beyound the precision of the platform, OS or perl (most restrictive win's) - e.g. "0.1E-4096" will _probably_ end up being represented as 0.0E0

Is it related to the binary storage and summing fractional powers of 2 e.g. a2^-1 + b2^-2 + c2^-2 ... where a,b,c... are 1 or 0.

Anyone have a view why string literal conversion of seemingly inoccuous floats has inaccuracies?

Comment on Still puzzled by floats

Replies are listed 'Best First'.

Re: Still puzzled by floats
by blakem (Monsignor) on Oct 07, 2002 at 06:30 UTC

9/10 + 5/100
[download]

1/2 + 1/4 + 1/8 + 1/16 + 0/32 + 0/64 + 1/128 + 1/256 +
0/512 + 0/1024 + 1/2048 + 1/4096 ...
[download]

0.95₍₁₀₎ ≈ 0.1111 0011 0011 0011 0011 0011 0011₍₂₎

But those last four bits repeat forever. Its exactly like writing 1/3 in base 10:

1/3 ≈ 0.33333333333333333333333333333333₍₁₀₎

-Blake

[reply]
[d/l]
[select]

Re: Still puzzled by floats
by hossman (Prior) on Oct 07, 2002 at 06:25 UTC

However, 19.95 can't be precisely represented as a binary floating point number,...,

Why not? Surely there is a bit pattern in the IEEE float format that precisely represents 19.95 (1.995E1). If a float is stored in,say, 32 bits on a particulat platfrom, some bits are for the mantissa and some are for the exponent...

That's not how it works.

What you are describing would be a base10 representation -- ie: you store a number and a base 10 exponent. What is typicaly used is a number and a base 2 exponent.

what you want:	mantissa * (10 ** exp)
what you get:	mantissa * (2 ** exp)

IEEE 854 specifies support for base10 representations, but no one uses it -- what gets used is IEEE 754. When you get a sizable chunk of free time, read through What Every Computer Scientist Should Know About Floating-Point Arithmetic -- in the mean time, John Darcy (Sun's floating point guru) has a great set of slides about Floats in java -- but the information is equally useful for perl programmers.

[reply]

Re: Still puzzled by floats
by abell (Chaplain) on Oct 07, 2002 at 07:04 UTC

A little addition to what others already said: in base d you can only represent exactly numbers expressed by fractions a/b with b a divisor of some power of d. In other words, to check if a reduced fraction a/b is expressable in finite form (not periodic) in base d, all prime divisors of b must also divide the base d.

Thus, 13/24 has a finite form in base 6, since 24=2^3*3, and both 2 and 3 are factors of 6, but not in base 10 or 2. 1/2 has a finite form in base 2 and 10, but not 3 and so on.

The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket

[reply]

Re: Still puzzled by floats
by BrowserUk (Patriarch) on Oct 07, 2002 at 06:32 UTC

The simple answer is that some decimal fractions cannot be accurately representred by binary fractions for similar reason as some ordinary fractions cannot be represented using decimal fractions.

1/3 is an exact value, but the closest we can get to representing it as a decimal fraction is 0.3333333333333...

No matter how many 3's you add after the decimal point, you have never quite accurately represented it.

Update: I couldn't work out how to easily show what I was trying to show, and the other posts say what I was trying to illustrate better than I was going to anyway.

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

[reply]

Re: Re: Still puzzled by floats

by jjdraco (Scribe) on Oct 07, 2002 at 07:24 UTC

jjdraco

learning Perl one statement at a time.

[reply]

Re: Still puzzled by floats
by maxomai (Initiate) on Oct 07, 2002 at 16:15 UTC

Math::FixedPrecision

Generally speaking you probably want something that handles Binary Coded Decimals to handle decimal data flawlessly. Most Intel archtechtures and lots of (other) languages support BCD.

Hope this helps.

[reply]

Re: Still puzzled by floats
by leriksen (Curate) on Oct 07, 2002 at 23:45 UTC

Thanx everyone, that was brilliant. I had the insight about infinite summation of fractional powers of two a couple of hours after I posted, but it's nice to see so many quality explanations and alternatives.

[reply]