Ahem, that was not the OP ... and by rounding, I meant that one version (by Monk::Thomas) processed 3.14159 as 3, and one version (by 1nickt) processed 3.14159 as 4.

AFAIK -- doesn't round to a whole number ...

[08:19][nick:~]$ perl -e '$foo=$ARGV[0];$foo--;print "$foo\n";' 3.1415
+9
2.14159
[download]

... and anyway, the other version without the decrementation rounded _up_ from 3.14159 to 4, which is what seems stranger.

I suppose it has to do with the difference between for(my $i = 0; $i < $n; $i++) and for my $i (0..$n) { ... but I can't see it from here. Good example of why you should examine and test everything, I guess.

1nickt:

Sorry about the misaddressed reply ... I just fixed it, thanks.

Expanding a bit, here's what's happening. For the first case, it's not rounding, it's just that 3 is less than 3.14159:

$ perl -e '$n=3; print "$n: "; for (my $i=0; $i<$n; $i++) { print $i,"
+ "} print "\n"'
3: 0 1 2

$ perl -e '$n=3.14; print "$n: "; for (my $i=0; $i<$n; $i++) { print $
+i," "} print "\n"'
3.14: 0 1 2 3
[download]

So the first loop only goes to 2 because 3 is not less than 3 (so the loop ends). In the second loop, though, 3 *is* less than 3.14, so it'll get to 3.

For the (0 .. $n) case it's somewhat different. There's still no rounding (though that's a pedantic nit.) I didn't read the code carefully, so I didn't notice that it used a different for-loop style, so The ".." operator

If you look at the documentation for the ".." operator (see perldoc perlop and page down to the "Range Operators" section) it describes how it works. However, it's *really* easy to miss^[1] one important fact about it: At the *very end* of the section, it gives this tidbit:

   Because each operand is evaluated in integer form, "2.18 .. 3.14" w
+ill
   return two elements in list context.

      @list = (2.18 .. 3.14); # same as @list = (2 .. 3);
[download]

In the second case, there's still no rounding--though that's just a pedantic nit^[2]. In fact, I didn't notice that the second script used a 0 .. $n style loop, so I shouldn't've said there's no rounding. I really need to be a bit more careful in reading code before commenting on it. I think I'll blame my eyes this time. Yeah, that's it.... ;^)

[1] It's easy to miss because they briefly discuss how it operates in list mode at the beginning, without mentioning that bit. Then a long discussion about how it works in scalar mode. Then, at the end, they give some examples of the operator, and slide that detail in at the very end. It may be a good idea to move the list mode examples above the scalar mode, and maybe add a "scalar mode" and "list mode" subheading to make it harder to miss. The version I'm looking at is v5.14, so it may have changed in the meantime.

[2] Technically truncating and rounding are different, but that's splitting hairs in casual discussion.

...roboticus

When your only tool is a hammer, all problems look like your thumb.