Re: Printf/Sprintf Behavior Change by McA (Priest) on Sep 16, 2013 at 16:37 UTC 
print sprintf("%0.02f",0.345);
is a little bit wrong. 0.345 rounded to two digits after the comma is 0.35 and not 0.34. You hit a classical floating point rounding error, Have a look at:
perl E 'print sprintf("%0.18f",0.346);'
If you do mathematics with this kind of rounding error you can be hit by such a phaenomena.
UPDATE: Look at this:
#!/usr/bin/env perl
use strict;
use warnings;
use 5.010;
use Data::Dumper;
my $l8 = 3.49;
my $l7 = 2;
my $subprice = 1.4;
my $tprice;
$tprice = ($l8/$l7)$subprice;
if ($tprice < 1 && length($tprice) > 4) {
print "SPRINTF  $tprice  " . sprintf("%0.18f",$tprice) . "\n";
}
McA  [reply] [d/l] [select] 
Re: Printf/Sprintf Behavior Change by kennethk (Abbot) on Sep 16, 2013 at 16:38 UTC 
printf "%0.018f\n", 0.345;
printf "%0.018f\n", (3.49 / 2)  1.4;
outputs (on my computer, it's platform dependent)
0.344999999999999970
0.345000000000000200
You are getting different numbers because you are dealing with different numbers. If you need absolute precision, there are ways to handle it, but they are generally not worth the effort it takes to implement them.
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
 [reply] [d/l] [select] 
Re: Printf/Sprintf Behavior Change by marinersk (Deacon) on Sep 16, 2013 at 18:02 UTC 
#!/usr/bin/perl w
use strict;
my $floatNumber = 0.345;
my $roundToTwoDecimals = int($floatNumber * 100) / 100;
printf "\$roundToTwoDecimals = %0.02f\n", $roundToTwoDecimals;
my $forcedRounding = int(($floatNumber + 0.005) * 100) / 100;
printf " \$forcedRounding = %0.02f\n", $forcedRounding;
exit;
__END__
C:\Steve\Dev\PerlMonks\P20130916@1955Rounding>rounding.pl
$roundToTwoDecimals = 0.34
$forcedRounding = 0.35
 [reply] [d/l] 

 [reply] 

Nice cheat sheet. Deposited one copy in my back pocket, and thanks for the link.
 [reply] 

The problem is NOT that printf is stupid.
Yes, if you implement your own "round to 2 decimal places" algorithm that doesn't actually round but instead truncates, then you'll (often) get a different answer than if you actually round (whether or not you use sprintf to actually round, which is one of the better choices available).
Specifically round arithmetically using your own rules and you should at least get consistent results.
See, that just proves that you didn't learn the lesson that a bunch of the other replies in this thread were trying to teach.
sub consistentlyRound {
my( $w ) = @_;
my $p = int( ($w+0.005)*100 );
return $p/100;
}
my $x = 0.015;
my $y = 0.0001;
$y += 0.0001 for 1..149;
print "x=$x y=$y\n";
printf "x~%.2f y~%.2f (stupid printf rounding)\n", $x, $y;
$x = consistentlyRound( $x );
$y = consistentlyRound( $y );
print "x~$x y~$y (consistent arithmetic rounding)\n";
__END__
x=0.015 y=0.015
x~0.01 y~0.01 (stupid printf rounding)
x~0.02 y~0.01 (consistent arithmetic rounding)
It is just that your arithmetic adds more floating point operations that can change the inconsistency! I can find cases where your particular arithmetic happens to be more consistent than sprintf's. Above I show a case where sprintf() is more consistent.
Now go read the other replies and/or what they link to more carefully and learn why.
 [reply] [d/l] 

Hello tye,
Thanks for the working example. You misunderstand some of what I posted, which is exacerbated by my use of nonspecific terminology ("truncation" vs. "rounding" is but one example).
At any rate, the thread presents a number of very useful references for anyone who wants or needs to understand how floating point operations work.
I haven't studied the mantissa translation issue for about 35 years; I understood it in a fairly detailed manner then, but have not needed to revisit it.
Without looking deeper into the issue, I suspect the problem your working example presents involves disparate precision reduction, a working case I have never been presented. All cases (unless my memory is failing, which is a distinct possibility) I have encountered in my career involved identical source and destinationprecision, and I cannot recall the "half next digit" technique ever failing me in that capacity.
I no longer remember if I proved it sufficient to the need or was merely shown the technique and accepted it. Suffice it is to say that my use of that technique has become so habitual as to defy academic defense.
Nonetheless, the technical content of your post is wonderful, as always, and I appreciate it.
 [reply] 
Re: Printf/Sprintf Behavior Change by boftx (Deacon) on Sep 16, 2013 at 23:57 UTC 
If one can infer that you are working with currency amounts, then I suggest taking a look at Math::Currency from CPAN to help alleviate/eliminate any rounding errors you encounter before any final formatting.
 [reply] 

 [reply] 
Re: Printf/Sprintf Behavior Change by Marshall (Prior) on Sep 17, 2013 at 07:37 UTC 
Well 0.34 and 0.35 could very well represent a similar value in binary that is rounded or truncated by different calculation methods.
I have one program that essentially says that: 0.34+.01 =equals 0.35+0.01. For a science program, that works great. These values are so close that the program figures that they are equivalent. And this is done in a DB in a very efficient way.
If you are calculating with money, eg. $15.34 vs $15.35, things get more complex. In that case what happens to the
.000012345 value matters (say an interest calculation).
Now things get more complex because the "rounded value" is not the only thing that matters. This "pesky whatever was leftover after the significant decimal points" matters also.
There is a thing called "BCD arithmetic". BCD means "Binary Coded Decimal". There are Perl subs that can do this type of arithmetic rather than binary, but this is a "lot slower".
However if you understand the rounding rules for Perl, you will be fine.
 [reply] 

However if you understand the rounding rules for Perl, you will be fine. Handsom too? Whats that mean "fine"
 [reply] 

"fine" means that you understand what is going to happen in whatever number base that you are calculating in. And that no matter what you do, there will most often be imperfect representations in either a decimal or binary format. For example: 1/3. If we aren't in base 3, there is going to be a precision problem.
 [reply] 