Mailing List Archive: 49091 messages

# mathematical rounding...

### [1/19] from: media:quazart at: 6-Nov-2001 10:33

Librarian comment

the round function is supplied as standard in REBOL 1.3 and later.

hi, What's the fastest algorythm to do rounding of decimal numbers... since rebol does not seem to have an explicit rounding function... to-integer only truncates... thanks! Max

### [2/19] from: roberth:utdallas at: 6-Nov-2001 9:36

For rational arithmetic on a computer look at www2.hursley.ibm.com and look at big decimal. bobh

### [3/19] from: ryanc:iesco-dms at: 6-Nov-2001 9:27

Here are some ones I tried that seem to be real fast: ; This is fastest, but is limited to positive integers. round: func [n] [ to-integer n + .5 ] ; This is the fastest for working with large decimals, but only does positive numbers... round: func [n] [ (n + .5) - ((n + .5) // 1) ] ; This does positive and negatives fine... round: func [n] [ (n: either n < 0 [ n - .5 ] [ n + .5 ]) - (n // 1) ] ; If you need to certain places do this: to-thousandth: func [n] [ (n: either n < 0 [ n - .0005 ] [ n + .0005 ]) - (n // .001) ] You can test your own with the program I have been using to improve my ray casters performance: do http://www.sonic.net/~gaia/misc/benchmark.r --Ryan Media wrote:
> hi, > What's the fastest algorythm to do rounding of decimal numbers... since
<<quoted lines omitted: 6>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 The contradiction so puzzling to the ordinary way of thinking comes from the fact that we have to use language to communicate our inner experience which in its very nature transcends lingistics. -D.T. Suzuki

### [4/19] from: greggirwin:mindspring at: 6-Nov-2001 10:58

Hi Max, Here's is Ladislav's rounding.r module, though there may be others out there as well. Rebol [ Title: "Rounding" Purpose: {Rounding functions} Author: "Ladislav Mecir" Date: 2/8/2000 Email: [lmecir--geocities--com] File: %rounding.r Category: [Math] ] mod: func [ {compute a non-negative remainder} a [number!] b [number!] /local r ] [ either negative? r: a // b [ r + abs b ] [r] ] round: func ["Round a number" n [number!] /places p [integer!] {Decimal places - can be negative} /local factor r ] [ factor: either places [10 ** (- p)] [1] n: 0.5 * factor + n n - mod n factor ] floor: func [ n [number!] /places p [integer!] {Decimal places - can be negative} /local factor r ] [ factor: either places [10 ** (- p)] [1] n - mod n factor ] ceiling: func [ n [number!] /places p [integer!] {Decimal places - can be negative} /local factor r ] [ factor: either places [10 ** (- p)] [1] n + mod (- n) factor ] truncate: func [ n [number!] /places p [integer!] {Decimal places - can be negative} /local factor r ] [ factor: either places [10 ** (- p)] [1] n - (n // factor) ] --Gregg

### [5/19] from: ryanc:iesco-dms at: 6-Nov-2001 10:23

Performance was pretty good for what you get, but not as fast as the functions I posted. One thing though...
>> round -5.5
== -5 This appears to be the wrong answer to me, but I am hardly a math scholar. Could someone please confirm. --Ryan Gregg Irwin wrote:
> Hi Max, > Here's is Ladislav's rounding.r module, though there may be others out there
<<quoted lines omitted: 60>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 The contradiction so puzzling to the ordinary way of thinking comes from the fact that we have to use language to communicate our inner experience which in its very nature transcends lingistics. -D.T. Suzuki

### [6/19] from: media:quazart at: 6-Nov-2001 13:44

If I recall, this is ok since: in negative, when you are at -5.5 you are actually closer to -5 (a larger value) than -6 (a smaller value) THANKS EVERYONE! -Maxim

### [7/19] from: media:quazart at: 6-Nov-2001 14:02

HI, Following the rounding question I have done some tests... and Tought I'd send this little note to everyone... Although this seems to be normal IEEE sanctioned behaviour, I have noticed that producing a floating point calculation with more than 15 characters of precisions as in: 1.499999999999999 will affect the actuall value of the flating-point number. evaluating the above actually returns 1.5 ... try it, you'll see ! so the above rounded return 2 not 1 !!! adding 0.5 to the above will cause an overflow to occur and 1.999999999999999... actually becomes 2.0 ! thanks for that excellent reference go to Robert Hamilton... This behaviour is mentioned and somewhat explained... in some of the pages when you dig a little bit... it seems to have to do with binary translation of decimal values (or something like that, excuse my gross interpretation)... Just thought I'd point it out since it isn't such an obvious side-effect to debug when coding... And Like many if you I'm not a scientific maths expert... making it THAT much less obvious... Ciao! -MAx

### [8/19] from: greggirwin:mindspring at: 6-Nov-2001 12:49

Hi Ryan, << Performance was pretty good for what you get, but not as fast as the functions I posted. One thing though...
>> round -5.5
== -5 This appears to be the wrong answer to me, but I am hardly a math scholar. Could someone please confirm. >> Hmmm. I haven't attempted to verify any of Ladislav's functions, but this is probably a bit of a gray area. I think "round" is a fairly generic term and may have different meanings in different contexts and programming languages. E.g. some do statistical rounding. This is another one of those times where a definitive set of documented library functions would be helpful. --Gregg

### [9/19] from: tomc:darkwing:uoregon at: 6-Nov-2001 12:26

in the case of .5 there is a choice and different results have been in vouge at different times "round to the even number" and "random" are a couple of strategies I recall but I think these days "round towards zero" is expected (the point of these equally (in)valid strateges is to minimize bias) On Tue, 6 Nov 2001, Gregg Irwin wrote:

### [10/19] from: lmecir:mbox:vol:cz at: 6-Nov-2001 21:36

>> round -5.5
== -5 This appears to be the wrong answer to me, but I am hardly a math scholar. Could someone please confirm. >> It is mathematically correct. (At least here in the Central Europe) Cheers Ladislav

### [11/19] from: larry:ecotope at: 6-Nov-2001 12:47

Hi Ryan, The standard rounding rule used in most numeric analysis packages (and also implemented as the default in IEEE Std 754 for binary floating point) is round nearest even . This means round to the nearest integer; in case of a tie make the least significant digit of the result an even number. Rounding even avoids bias in the result if the digits to be rounded off occur with equal frequency. Of course, rounding odd would work just as well, but the chosen convention is to round even. In base 10, rounding goes like this: 5.1 thru 5.4 rounds to 5 5.5 rounds to 6 5.6 thru 5.9 rounds to 6 -2.5 rounds to -2 -1.5 rounds to -2 -0.5 rounds to 0 0.5 rounds to 0 1.5 rounds to 2 2.5 rounds to 2 etc. Negatives are just the mirror image, so the correct answer is: -5.5 rounds to -6 Note that 5.5 is exact in both base 10 arithmetic and in base 2 arithmetic, so in this case there is no problem due to conversion between bases. However, in general, the base conversion will introduce further issues. For a set of functions which handle all the gory details for rounding doubles of any size in REBOL, see the scripts format.r and decimal.r on the Ecotope rebsite. www.nwlink.com/~ecotope1/reb/format.r www.nwlink.com/~ecotope1/reb/decimal.r The format function gives this result:
>> format -5.5 #0
== "-6" -Larry

Amazing.

### [13/19] from: alans:cuervo:stanford at: 6-Nov-2001 13:25

> Hi Ryan, > << Performance was pretty good for what you get, but not as fast as the
<<quoted lines omitted: 10>>
> This is another one of those times where a definitive set of documented > library functions would be helpful.
There are several accepted methods of rounding. One version for rounding from 0.5 says to round up if the number to the left of the decimal is even, and truncate if it is odd. The purpose (hope) is to randomize the error so any statistics behave better.
> --Gregg > > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes. >
--Alan <[swithenbank--acm--org]>

### [14/19] from: alans:cuervo:stanford at: 6-Nov-2001 13:30

from: Gregg
> Hi Ryan, > << Performance was pretty good for what you get, but not as fast as the
<<quoted lines omitted: 10>>
> This is another one of those times where a definitive set of documented > library functions would be helpful.
There are several accepted methods of rounding. One version for rounding from a 5 (i.e., 0.5, 0.05, etc.) says to round up if the number to the left is even, and truncate if it is odd. The purpose (hope) is to randomize the error so any statistics behave better.
> --Gregg > > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes. >
--Alan <[swithenbank--acm--org]> --NAB15699.1005081923/cuervo.Stanford.EDU--

### [15/19] from: alans:cuervo:stanford at: 6-Nov-2001 13:45

> There are several accepted methods of rounding. One version for rounding > from a 5 (i.e., 0.5, 0.05, etc.) says to round up if the number to the left > is even, and truncate if it is odd. The purpose (hope) is to randomize the > error so any statistics behave better.
interesting...the first try I received a bounce, so I sent again, but apparently it also went through...? --Alan <[swithenbank--acm--org]>

### [16/19] from: greggirwin:mindspring at: 6-Nov-2001 15:27

Hi Alan, << There are several accepted methods of rounding. One version for rounding from 0.5 says to round up if the number to the left of the decimal is even, and truncate if it is odd. The purpose (hope) is to randomize the error so any statistics behave better. >> Right. That's what I meant by statistical rounding. --Gregg

### [17/19] from: rpgwriter:y:ahoo at: 6-Nov-2001 14:36

--- Thomas E Conlin <[tomc--darkwing--uoregon--edu]> wrote:
> in the case of .5 there is a choice and different > results have been in
<<quoted lines omitted: 5>>
> (the point of these equally (in)valid strateges is > to minimize bias)
I've almost universally seen (except when there was a specific reason for using another method) round *away* from zero at 0.5 as the standard. Chris Dicely

### [18/19] from: rpgwriter::yahoo::com at: 6-Nov-2001 14:47

--- Gregg Irwin <[greggirwin--mindspring--com]> wrote:
> Hi Alan, > << There are several accepted methods of rounding.
<<quoted lines omitted: 5>>
> so any statistics behave better. >> > Right. That's what I meant by statistical rounding.
Right. Other schemes try to preserve different features. Examples Round even (or odd) guarantees that: 1) if integer-parts are evenly distributed, rounding bias cancels. 2) round(-x) equals -round(x) Round toward (or away from) zero guarantees that: 1) round(-x) equals -round(x) 2) if (sign(x)=sign(x+1)) round(x)+1 = round(x+1) Round greater (or less) guarantees that: 1) round(x)+1 = round(x+1) This isn't exhaustive, merely illustrative. In different applications, different behaviors may be most desirable.

### [19/19] from: alans:cuervo:stanford at: 6-Nov-2001 14:50

> --- Thomas E Conlin <[tomc--darkwing--uoregon--edu]> wrote: > >
<<quoted lines omitted: 11>>
> a specific reason for using another method) round > *away* from zero at 0.5 as the standard.
That would preferentially add more error to sums, and cause problems with statistics, unless you could guarantee a random distribution of positive and negative numbers in the set you are working with.
> Chris Dicely > __________________________________________________
<<quoted lines omitted: 5>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
--Alan <[alans--cuervo--stanford--edu]>

Notes
• Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted