Re: strange rounding behaviour

I always round like this:

#round $num to 2 decimal places
$rounded = int(0.5+$num*100)/100;
[download]

That code doesn't seem to exhibit the strange behavior you see when sprintf for rounding.

In case you care about performance, the INT version I describe is more than 2.5 times as fast as the sprintf version:

Benchmark: running RoundINT, RoundSPRINTF, each for at least 3 CPU seconds...
  RoundINT:  3 wallclock secs ( 3.15 usr +  0.00 sys =  3.15 CPU) @ 7753.02/s (n=24422)
RoundSPRINTF:  3 wallclock secs ( 3.21 usr +  0.00 sys =  3.21 CPU) @ 2906.85/s (n=9331)

Comment on Re: strange rounding behaviour Download Code

Replies are listed 'Best First'.
Re (tilly) 1: strange rounding behaviour by tilly (Archbishop) on May 18, 2001 at 20:09 UTC
`print int(0.5 + 0.695*100)/100;` [download] prints 0.7 for me. Thereby showing that your round does not get the formatting correct which sprintf does, and still suffers from inconsistent rounding behaviour. The reasons for this behaviour are basic to the fact of how floating point numbers work. They may not be readily predictable (exact details depend on your chip, OS, compiler, etc) but the underlying issue is that the internal representation of a floating point number is in base 2, while the visible one is in base 10. Therefore when you go to represent a floating point number, a nice round number base 10 turns into a repeating representation that is always stored with round-off error. What way you round in the boundary case depends on the interaction of that error and your operations.	[reply] [d/l]
Re: Re (tilly) 1: strange rounding behaviour by lhoward (Vicar) on May 18, 2001 at 20:35 UTC
Nice catch tilly. I missed that case. My opinion boils down to this: use string formatting routines for formatting strings (not rounding numbers), and use numeric tools for numeric operations (like rounding). Using a string operator (like sprintf) to do a numeric function (rounding) is just asking for "unexpected complications".	[reply]