 Clear questions and runnable codeget the best and fastest answer PerlMonks

### float values and operators

by soulchild (Acolyte)
 on Aug 11, 2004 at 19:59 UTC Need Help??

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

Today I stumbled across the following piece of code and I'm still wondering why the condition is not met:
```my \$a = 36.8;
my \$b = 36.6;
if( \$a >= ( \$b + 0.2 ) ) { print "true\n"; }
[download]```
=> returns nothing (Why's that? 36.8 equals 36.6 + 0.2)

Whereas the condition becomes true if I change the values a little bit:
```my \$a = 6.8;
my \$b = 6.6;
if( \$a >= ( \$b + 0.2 ) ) { print "true\n"; }
[download]```
=> returns "true" (that's what i expected)

I feel a little bit stupid asking this question and have the strange feeling that my mind is playing a trick on me here because I've been doing perl stuff since many years now. Must have got something to do with floating point values and the "greater or equal than" operator, I guess.

Could somebody please tell me why the above code fragments work like they do and not how I think they should work?

Thanx!

Replies are listed 'Best First'.
Re: float values and operators
by Zaxo (Archbishop) on Aug 11, 2004 at 20:07 UTC

You're hitting a fundamental problem with representing decimal fractions in binary form. It is a limitation of your processor's floating point arithmetic which is exhibited in all languages, not just perl. You can eliminate the problem by rounding with sprintf before comparison.

After Compline,
Zaxo

Hi Zaxo,

I noticed that this doesn't happen in C ...
```bash-2.05b\$ cat float.c
#include <stdio.h>

int main () {
float a = 36.8;
float b = 36.6;
if( a >= ( b + 0.2 ) ) { printf ("true\n"); }
}
bash-2.05b\$ gcc -o float float.c
bash-2.05b\$ ./float
true
[download]```
... and does happen in Python ...
```bash-2.05b\$ cat float.py
#!/usr/bin/python
A = 36.8
B = 36.6
if( A >= B + 0.2 ):
print "true"
else:
print "false"
bash-2.05b\$ ./float.py
false
[download]```
I would of included a java example but I aint got all day to download the SDK. Maybe I'll update with one later. Can you explain why C deals with float point number while Perl and Python appear to have this problem? Is it a compiled verses and interpreted language issue?

Thanks

 Plankton: 1% Evil, 99% Hot Gas.

Are you sure C "deals"?

```\$ cat imprec.c
#include <stdio.h>

int main () {
float fa = 36.8;
float fb = 36.6;
double da = 36.8;
double db = 36.6;
printf( ( fa >= ( fb + 0.2 ) ) ? "true\n" : "false\n" );
printf( ( da >= ( db + 0.2 ) ) ? "true\n" : "false\n" );
}
\$ gcc -o imprec imprec.c
\$ ./imprec
true
false
[download]```

You're seeing the result of cut-off caused by float's lower precision.

Perl and Python use doubles in all floating point operations.

Makeshifts last the longest.

C doesn't deal, actually:

```\$ cat a.c
#include <stdio.h>
int main() {
printf("%s\n", 36.6 == 36.8-0.2 ? "true" : "false");
return 0;
}
\$ gcc a.c
\$ a.out
false
[download]```

That's what I thought, too, but it doesn't appear to be the case:

```\$ perl -le '\$a = 36.8; \$b = 36.6; print "true\n" if \$a >= (\$b + 0.2);'
# Prints nothing, just as poster showed

\$ perl -le '\$a = 36.8; \$b = 36.6; \$c = \$b + 0.2; print \$c;'
36.8

\$ perl -le '\$a = 36.8; \$b = 36.6; \$c = \$b + 0.2; print \$a;'
36.8

\$ perl -le '\$a = 36.8; \$b = 36.6; \$c = \$b + 0.2; print \$b;'
36.6
[download]```

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

```\$ perl -e'print 36.8 - (36.6 + 0.2)'
-7.105427357601e-15
[download]```

After Compline,
Zaxo

You're right. Using sprintf to round the values before comparison does the job. Nevertheless I didn't quite understand why this is necessary. Could somebody explain this a little bit more verbose? Thanks a lot, guys!
Recipe 2.2 in the Perl Cookbook, Second Edition is excellent reading on this subject.

Basically, when you use a floating point number, such as 36.6, the computer doesn't store that exact value. Remember, computers are binary. When you get down to it, there's nothing more than transistors. The memory storage only really works well for integers. So the computer has to figure out some way to store approximations of the number.

To paraphrase the cookbook, the only numbers well-representable in binary are those involving powers of two. For example, .125 is 1/8. That's exactly representable in binary notation of floating point numbers.

However, take a number like 36.6. In fractional form, it would be 183/5, nothing to do with powers of two. The way the computer really stores the number can be seen:

```my \$a = 36.6;
printf "%s is %.30g\n", (\$_) x 3 for \$a;
[download]```
(Code shamelessly copied from the Perl Cookbook.)

That gives us 36.600000000000001. Similarly, 36.8 is given as 36.799999999999997.

So now you see why the comparisons failed. You weren't working with exact values.

Perl's (and indeed, the C library's) rounding function are not exactly ``round up at five,'' but actually ``round towards even.'' So that way, sprintf will round 36.6 to an even 36.6 for calculating. So now, numerical comparisons work with nice and even numbers.

Take a look at the Perl Cookbook on this one. It's a very good read. I've just summarised what it has written very well.

[Why] Re: float values and operators
by Zaxo (Archbishop) on Aug 11, 2004 at 20:52 UTC

Here's a short explanation of what happens.

Recall that when a ratio of integers (a rational number) is shown in decimal form, the decimal fraction terminates only if the integers have denominator has no factors but 2 and 5. Thus one-eighth == 0.125 and two-fifths == 0.4, but one-third == 0.33333333.... and one-seventh == 0.142857142857.... .

The same thing happens with n-al fractions in any base n. Processors represent floats in base two, so any rational fraction with a factor of 5 forms an infinite repeating pattern of ones and zeros. The processor can only hold a finite number of the leading bits, so the floating point representation of 182/5 == 36.2, 183/5 == 36.4, and 1/5 == 0.2 are all low-side approximations. When they are added and subtracted, the results are internally rounded from a few extra bits the processor keeps hidden, with the confounding result that floating-point addition is not even associative!

After Compline,
Zaxo

Re: float values and operators
by itub (Priest) on Aug 11, 2004 at 21:33 UTC
Rule #1 of floating-point computing in any language, not just Perl: Never compare two floating-point numbers with == or != (or expect >= et al. to work in the edge cases). Use a tolerance range instead. Other monks have already explained the cause behind this numerical imprecision.

For a detailed explanation, see Comparing floating point numbers

Re: float values and operators
by ikegami (Pope) on Aug 11, 2004 at 21:21 UTC

Here's how to get around the problem:

```sub TOLERANCE () { 1e-13 }

sub are_equal {
my (\$a, \$b) = @_;
return (abs(\$a-\$b) < TOLERANCE);
}

print('==:        ',    (36.8 == 36.6+0.2)     ?'equal':'unequal', "\n
+");
print('are_equal: ', are_equal(36.8, 36.6+0.2) ?'equal':'unequal', "\n
+");

__END__
output
======
==:        unequal
are_equal: equal
[download]```

I went nuts and here's a more general compare function (works like <=>)

```sub TOLERANCE () { 1e-13 }

sub compare {
my (\$a, \$b, \$tol) = @_;
\$tol = TOLERANCE unless (defined(\$tol));
my \$diff = (\$a - \$b);
if (\$diff > +\$tol) { return +1; }
if (\$diff < -\$tol) { return -1; }
return 0;
}

sub format_cmp {
my (\$cmp) = @_;
if (\$cmp <  0) {return "<"; }
if (\$cmp == 0) {return "="; }
if (\$cmp >  0) {return ">"; }
}

print('35   <=> 36       = ', format_cmp(35   <=> 36      ),  '   ', f
+ormat_cmp(compare(35,   36      )), ' = compare(35,   36      )',  "\
+n");
print('35   <=> 35       = ', format_cmp(35   <=> 35      ),  '   ', f
+ormat_cmp(compare(35,   35      )), ' = compare(35,   35      )',  "\
+n");
print('36   <=> 35       = ', format_cmp(36   <=> 35      ),  '   ', f
+ormat_cmp(compare(36,   35      )), ' = compare(36,   35      )',  "\
+n");
print('36.8 <=> 36.6+0.2 = ', format_cmp(36.8 <=> 36.6+0.2),  '   ', f
+ormat_cmp(compare(36.8, 36.6+0.2)), ' = compare(36.8, 36.6+0.2)',  "\
+n");

__END__
output
======
35   <=> 36       = <   < = compare(35,   36      )
35   <=> 35       = =   = = compare(35,   35      )
36   <=> 35       = >   > = compare(36,   35      )
36.8 <=> 36.6+0.2 = <   = = compare(36.8, 36.6+0.2)
[download]```
Re: float values and operators
by GreyGlass (Sexton) on Aug 12, 2004 at 04:27 UTC
The theory was well illuminated by others. The nuts and bolts (or the bits) in this case are:
```> perl -le "print unpack q/b*/, pack F, 36.8"
0110011001100110011001100110011001100110011001100100001000000010

> perl -le "print unpack q/b*/, pack F, 36.6+.2"
1110011001100110011001100110011001100110011001100100001000000010
[download]```

As you can see, there is a bit of difference. The lowest-order bit, to be exact.

FYI: This, of course, is on Win32. On other platforms it may be different, both in encoding and the round-off error in the last bit.

Log In?
 Username: Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://382071]
Approved by NovMonk
Front-paged by derby
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2021-04-21 03:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?

No recent polls found

Notices?