Both 1/10 and 16/10 are periodic numbers in binary, just like 1/3 is in decimal. It would take an infinite amount of memory to store 0.1 and 1.6 as floats. Some rounding error occurs.

$ perl -e' printf "%.20f\n", 1.6;'
1.60000000000000008882
[download]

$ perl -e'
   for ($i=1.1;$i<=1.6;$i+=.1) { printf "%.20f\n", $i; }
   printf "\n%.20f\n", $i;
'
1.10000000000000008882
1.20000000000000017764
1.30000000000000026645
1.40000000000000035527
1.50000000000000044409

1.60000000000000053291
[download]

One solution is to use integers for the counter, and generate the floats from them

$ perl -le'for my $i (1..6) { print 1+$i/10 }'
1.1
1.2
1.3
1.4
1.5
1.6
[download]

It gives precise checks for the loop, and there's no accumulation of error for the result.

• What Every Computer Scientist Should Know About Floating-Point Arithmetic
• Why does printf() do this to big numbers?
• printf question
• sprintf rounding convention

The recommendation from my numerical analysis course was to use a "delta" value when comparing, depending on "how close" the values needed to be for you to decide they were equal.

Something like

while ($i - $j < $delta) {
  ...
}
[download]

The trick is selecting a delta that works. For instance if $i was 2E40 and $j was 1E40, selecting a delta of 1E-40 probably wouldn't work - it's going to depend on how many significant figures your platform's floating point numbers can represent (the example above would require 80 significant figures, if I'm remembering all this right: 40 in front of the decimal point and 40 after it). You should carefully check out your platform's floating point representation and precision before embarking on adventures in floating point computations.

This is why many financial calculations in which it was necessary to be precise about exact cents used to be (and probably are still) done in cents rather than in fractional dollars - you can precisely add and subtract integers as long as you have enough digits to represent the amounts you care about.

Most accounting and telecommunications charging tables that I've worked with were to the fourth decimal place. This wasn't in perl but same applied, we ended up using a math library which used BCD or similar, which produces much better results and rounding functions than floating point. But that's probably beside the point. You can also create an "artificial" loop variable that counts in integers instead of decimals..since you know the number of steps.
the hardest line to type correctly is: stty erase ^H

That will only help if the rounding error make the number slightly larger. It doesn't help if the rounding error makes the number slightly smaller, and that does happen. It's not a good solution.

That would be perlnumber or perldoc perlnumber, in case you don't know where to find it.