Rounding a number to nearest even
Lie
Lie.1296 at gmail.com
Thu Apr 17 21:35:25 CEST 2008
On Apr 13, 7:20 pm, Steve Holden <st... at holdenweb.com> wrote:
> Lie wrote:
> > On Apr 12, 3:44 am, hdante <hda... at gmail.com> wrote:
> [snip]
>
> > In short, choosing that x.0 is rounded down and x.5 is rounded up is
> > arbitrary but not without a reason.
>
> Don't "arbitrary" and "not without a reason" directly contradict one
> another?
>
The same as choosing between round-half-odd and round-half-even,
arbitrary but not without a reason.
Language-wise it is a contradiction. In a loose semantic meaning, it
means there is no strong reason for choosing one above the other
(round-up vs round down and round-half-even vs round-half-odd) but
there are slight advantages on one that would seems silly to be
mentioned as the main reason, so arbitrary but not without reason.
On Apr 13, 9:28 pm, Mark Dickinson <dicki... at gmail.com> wrote:
> On Apr 13, 4:18 am, Lie <Lie.1... at gmail.com> wrote:
> [...]
>
> > it and there is nothing else in it, but in the second number range
> > (barely above 1 to 2) the number 1.0 is not included while the number
> > 2.0 is contained in it, clearly not a clean separation of numbers in
> > the form of y.x where y is pre-determined and x is variable from other
> > possible values of y.
>
> Have you considered the fact that the real numbers of
> the form 1.xxxxx... are those in the range [1.0, 2.0],
> including *both* endpoints? That is, 2.0 = 1.999999...
> Similarly, the midpoint of this range can be written
> both in the form 1.500000... and 1.499999...
No, you can only include one of the endpoints, because if both
endpoints are included, the integers would be a included twice on the
various sets of numbers, e.g. in [1.0 - 2.0] and [2.0 - 3.0] the
number 2.0 is included in both ranges, you can't be a member of both
ranges because that means if you have a "fair" random number
generator, the possibility of integral number to appear would be twice
the possibility of non-integral numbers, well that's not a fair random
number generator isn't it?
> This is relevant if you think of rounding as an operation
> on *decimal representations* of real numbers rather than
> as an operation on real numbers themselves. I'm not sure
> which point of view you're taking here.
Actually, I'm on the side that think numbers should never be
rounded[1], except for a final representation to human viewer who
should be made aware that the numbers in the presentation should never
be used for further calculation, as they are only informative but not
normative. In this view, the exact rounding method is irrelevant as
numbers used for calculation are never rounded while at the lower
level the amount of change caused by rounding has become irrelevant
because of the extra precision used. In short, if the rounding
algorithm causes you a trouble in the particular field, increase the
precision.
[1] As computers do have limitation on storage of real number
representation, this statement means that real numbers should be kept
as precise as the hardware allows or to use decimal and allow extra
precision generously.
> Either way, your arguments don't change the fact that the
> average rounding error is strictly positive for positive
> quantized results, under round-half-away-from-zero.
If you include negative numbers, the ARE is zero on round-half-away-
from-zero, not in round-up though.
More information about the Python-list
mailing list