in reply to Re: rounding to nearest integer
in thread rounding to nearest integer

Note that sprintf will round values exactly halfway between two numbers (0.5 + int $X) up for odd and down for even numbers to avoid a bias toward rounding up.

Makeshifts last the longest.

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

Replies are listed 'Best First'.
Re^3: rounding to nearest integer (rounding bias)
by halley (Prior) on May 11, 2003 at 16:13 UTC

    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 ]

      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.

        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 ]