Re:x4 rounding to nearest integer (rounding bias)

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.

Comment on Re:x4 rounding to nearest integer (rounding bias)

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]