Re^3: rounding to nearest integer (rounding bias)

I've heard that proposed many times, but I think it's a fallacy. Should you alternate between rounding N.0 up and down also? N.5 needs to be rounded up, and -N.5 needs to be rounded down.

For any integer N, for all reals in the range [ N, N+1 ), that is, including N but not quite including N+1, then N+0.5 is in the upper half of the range closest to N+1, while anything less is in the lower half of the range closest to N.

--
[ e d @ h a l l e y . c c ]

Comment on Re^3: rounding to nearest integer (rounding bias)

Replies are listed 'Best First'.
Re:x4 rounding to nearest integer (rounding bias) by grinder (Bishop) on May 11, 2003 at 19:56 UTC
You only think it's a fallacy. I wrote some code to prove that it's true at counter-intuitive sprintf behaviour. Of special interest is merlyn's reply. At least now I understand why it is so, even if I still think the results are peculiar. _____________________________________________ Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.	[reply]
Re: Re:x4 rounding to nearest integer (rounding bias) by halley (Prior) on May 11, 2003 at 20:53 UTC
I didn't refute that sprintf acts the way it does. I just think it's numerically wrong to "round" a number down if it's in the upper half of an intra-integer span. Half the numbers in [N,N+1) should go up, half the numbers down. Rounding everyday numbers should not be as complex as deciding when to add a leap-second the clock. If you're a mathematician, you should know that you shouldn't leave numbers to the whims of crappy implementations in runtime libraries: calculate what you want in your own code, and understand the limitations of the hardware you're using. -- `[ e d @ h a l l e y . c c ]`	[reply]