This is the result of storing floating point numbers in base two. Consider the fraction 1/3rd. Expressed in decimal, that's 0.33 (repeating forever). Add 0.33 three times, and you get 0.99, not one. You can extend to as many decimal places as you like, you'll never get .3333333333333333333333333 * 3 to add up to 1.0. Well, in base 2, the fraction 1/10th has a non-terminating expansion. So 0.1 has to be stored as 0.09999999999999999 or something similar, and when you add that up ten times you won't get to one.

It's only shocking because you grew up with base-ten and are so accustomed to seeing the problem that you don't notice it until it turns up in another base system.

Of course this is not unique to Perl. Consider the following C++ code:

#include <iostream>
#include <iomanip>


int main () {

  double n = 0.0;
  for( int i = 0; i != 10; i++ ) {
    n += 0.1;
    std::cout << std::setprecision(16) << std::fixed << n << std::endl
+;
  }

  if( n != 1.0 )
    std::cout << "Whoops, " << n << " isn't equal to 1.0." << std::end
+l;

  return 0;
}
[download]

...outputs...

0.1000000000000000
0.2000000000000000
0.3000000000000000
0.4000000000000000
0.5000000000000000
0.6000000000000000
0.7000000000000000
0.7999999999999999
0.8999999999999999
0.9999999999999999
Whoops, 0.9999999999999999 isn't equal to 1.0.
[download]

use warnings;
use strict;

my $range = 0.1;
my $i     = 0;
while ( $i < 1 ) {
    print $i. "\n";
    $i = sprintf '%.1f', $i + $range;
}

__END__

0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
[download]

• Why am I getting long decimals (eg, 19.9499999999999) instead of the numbers I should be getting (eg, 19.95)?

And, of course, the obligatory What Every Computer Scientist Should Know About Floating-Point Arithmetic (which has probably already been referenced via a link in another reply, but what the heck...).

Or a even Is this odd behavior a floating point problem?

This is just another way of saying the same thing but in Perl 0.1 isn't the value you think it is. Try the following:

printf("%.64f\n", 0.1);
[download]

On my system it prints:

0.1000000000000000100000000000000000000000000000000000000000000000
[download]

Note the extra 1 in the 17th place. The result may be different on your system. It depends on how floating point numbers are stored. Different systems store them differently.

"Why the "1" at the end? "

When I used lt instead of < operator, it works as you expected. Still, lt operator used for comparing strings not for numerals. As per my understanding, perl tries to implicitly convert both $i and 1 as strings and do comparison. If somebody finds different reason for it, kindly clarify me.

my $range = 0.1;
my $i = 0;
while( $i lt 1 )
{
    print $i."\n";    
    $i = $i + $range;
}
[download]

perl -E say 'Ouch!' if '0002' lt 1;

Ouch!

I would recommend caution if you're going to go down that road. The best thing to do is to simply understand the nature of floating point precision and deal with it in the most straight-forward way possible. Stringification has its uses, but bending the rules of numeric relational comparisons is probably not an ideal one.




Dave

This is one of the flaws in Perl. It usually makes your life so easy by providing simple means to achieve complex tasks that one often forgets that it is a mere programming language. (Hope this does not count as heresy.)