in reply to Re: Printf/Sprintf Behavior Change in thread Printf/Sprintf Behavior Change
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.
Re^3: Printf/Sprintf Behavior Change (stupid printf) by marinersk (Curate) on Sep 17, 2013 at 09:25 UTC 
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] 
