[racket] Rounding
Eric Nadeau
I was having problems with a mathematical application I'm writing and narrowed it down to:
(round 0.5)
(round (/ 1 2))
(round 1.5)
(round (/ 3 2))
giving me
0.0
0
2.0
2
Since when is round 0.5 not giving 1?!
Cheers,
Eric
____________________
Racket Users list:
http://lists.racket-lang.org/users
Nadeem Abdul Hamid
--- nadeem
Eric Dobson
floating point numbers [1]. You can write your own rounding operator
that rounds .5 up if need be.
;; Untested
(define (my-round n)
(let ((r (round n))) (if (= .5 (- n r)) (add1 r) r)))
[1] http://en.wikipedia.org/wiki/Rounding#Round_half_to_even
Danny Yoo
> Since when is round 0.5 not giving 1?!
http://docs.racket-lang.org/reference/generic-numbers.html#%28def._%28%28quote._~23~25kernel%29._round%29%29
"Returns the integer closest to x, resolving ties in favor of an
even number... "
And zero is an even number. (http://www.bbc.co.uk/news/magazine-20559052)
So although it may be surprising, at least the behavior is documented.
Mathworld and Wikipedia say that this is done to combat statistical biasing:
http://mathworld.wolfram.com/NearestIntegerFunction.html
http://en.wikipedia.org/wiki/Rounding#Round_half_to_even
Carl Eastlund
This is also untested. And it might need tweaking for negative numbers if they are supposed to round away from zero, I forget how that works.
mi...@goblin.punk.net
> Since when is round 0.5 not giving 1?!
(http://physics.nist.gov/cuu/Units/rules.html)
Eli Barzilay
> That's an overly specific solution. I believe the more general rounding
> function taught in grade-school math would be:
>
> (define (my-round n)
> (floor (+ n 1/2)))
If you want 0.5 to round down to 0, then
(define (my-round n) (ceiling (- n 1/2)))
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Neil Toronto
>>
>> Since when is round 0.5 not giving 1?!
>
> According to the documentation:
>
> http://docs.racket-lang.org/reference/generic-numbers.html#%28def._%28%28quote._~23~25kernel%29._round%29%29
>
> "Returns the integer closest to x, resolving ties in favor of an
> even number... "
>
> And zero is an even number. (http://www.bbc.co.uk/news/magazine-20559052)
>
> So although it may be surprising, at least the behavior is documented.
>
>
>
> Mathworld and Wikipedia say that this is done to combat statistical biasing:
>
> http://mathworld.wolfram.com/NearestIntegerFunction.html
> http://en.wikipedia.org/wiki/Rounding#Round_half_to_even
This is the reason the *low-order bit* of a floating-point number (or
any finite-precision number) is rounded with ties toward even. Assuming
that the unrepresented bits are distributed uniformly, it tends to make
sums of values that are rounded multiple times more accurate.
IMO, the reason floating-point hardware rounds toward even for integer
rounding is code reuse. Its bias correction is miniscule to nonexistent
at that magnitude, unless you round after nearly every operation.
Here's a demo:
#lang typed/racket
(require math)
(: round/ties-toward-zero (Real -> Real))
;; Like the rounding we learned in school
(define (round/ties-toward-zero x)
(if (x . < . 0)
(- (round/ties-toward-zero (- x)))
(floor (+ x 1/2))))
(: double-rounding-error ((Real -> Real) Real (Listof Real) -> Real))
;; Round every x once to the nearest `low-bit', then compare the sum
;; of those with the sum of them rounded to the nearest integer
(define (double-rounding-error round low-bit xs)
(let ([xs (map (λ: ([x : Real])
(* low-bit (round (/ x low-bit))))
xs)])
(absolute-error (sum xs) (sum (map round xs)))))
;; Get some random numbers
(define xs (sample (uniform-dist 0 10) 10000))
;; Wow, this really helps if the second rounding is near the magnitude
;; of the low-order bit
(double-rounding-error round 1/2 xs)
(double-rounding-error round/ties-toward-zero 1/2 xs)
;; If the low-order bit is much smaller, though, it doesn't help at all
(double-rounding-error round 1/512 xs)
(double-rounding-error round/ties-toward-zero 1/512 xs)
;; Also, if we violate assumptions, it doesn't help as much (in this
;; case, the violated assumption is that there are as many values near
;; odd numbers as near even numbers)
(define ys (sample (uniform-dist 0 3) 10000))
(double-rounding-error round 1/2 ys)
(double-rounding-error round/ties-toward-zero 1/2 ys)
;; Violated assumption: missing bits are approximately uniformly
;; distributed (still does okay, though)
(define zs (map flsqrt (sample (uniform-dist 0 100) 10000)))
(double-rounding-error round 1/2 zs)
(double-rounding-error round/ties-toward-zero 1/2 zs)
Neil ⊥
Eric Nadeau
The point of rounding is coming up with the best possible integer approximation for a decimal and this nearest even number rule does not qualify. This "logic" was used by my grandparents' generation because odd numbers were seen as less pure than even ones.
I'm ditching Scheme altogether based on this, but thanks all for the good explanations, it can be confirmed by running the following (I thought it was only a fluke with 0.5):
(round 0.5) (round 1.5) (round 2.5) (round 3.5)
Robby Findler
Danny Yoo
of rounding toward even. Read again.
> I'm ditching Scheme altogether based on this, but thanks all for the good explanations, it can be confirmed by running the following (I thought it was only a fluke with 0.5):
see that the rounding behavior in Racket is not arbitrary, nor
exclusive to Racket alone. Your comment seems to suggest that you
believe otherwise, but I have no idea why. Did you read what people
have sent you?
It would be useful to know more of what you expected. Are you
expecting rounding toward odd? You omitted to say much. Did you want
the ceiling function? Did you want round-half-up? What did you want?
Stephen Bloch
On Mar 16, 2013, at 11:47 PM, Eric Nadeau <nad...@gmail.com> wrote:
> The point of rounding is coming up with the best possible integer approximation for a decimal and this nearest even number rule does not qualify.
> This "logic" was used by my grandparents' generation because odd numbers were seen as less pure than even ones.
On the contrary, my impression is that our grandparents' generation chose "round halves up" because the most common source of decimal numbers that needed rounding was long division, which generates decimal digits one at a time. If you generated the first digit after the decimal point and you got a "5", it meant the remainder was AT LEAST half of the divisor, but possibly more, so rounding halves up meant that you'd never round in the wrong direction, and most of the time (1 - 1/divisor) you'd be rounding in the right direction. (The remaining 1/divisor of the time would be the "exact half" case in which either direction would be equally close.)
In computer arithmetic, by contrast, typically all the bits are generated (including guard, round, and sticky bits) before you even think about rounding, so you don't need to make your rounding decision based on only the first digit after the point.
> I'm ditching Scheme altogether based on this, but thanks all for the good explanations, it can be confirmed by running the following (I thought it was only a fluke with 0.5):
>
> (round 0.5) (round 1.5) (round 2.5) (round 3.5)
BTW, before you blame this on Scheme or Racket, see http://docs.oracle.com/javase/1.5.0/docs/api/java/math/RoundingMode.html and http://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules
Stephen Bloch
sbl...@adelphi.edu
Neil Toronto
> I'm ditching Scheme altogether based on this...
In case you're not trolling: changing languages won't help. This is
standard behavior. And for goodness sake, you can always write your own
function!
Neil ⊥
Robby Findler
Matthew Flatt
> > http://lists.racket-lang.org/**users <http://lists.racket-lang.org/users>