Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: st: round() for values ending in 5
From
Nick Cox <[email protected]>
To
"[email protected]" <[email protected]>
Subject
Re: st: round() for values ending in 5
Date
Mon, 20 Jan 2014 18:22:34 +0000
Not the answer you seek, but for fractional arguments, I've found it
best not to think of -round()- as producing decimal results at all.
-round()- can only produce a number with a binary representation, just
like any other numeric function.
For example, although as you point out 4.5 has an exact binary
representation, that is not true of 4.55, so your example can't be
discussed without discussing how well 4.55 can be approximated as a
binary number.
Why do you want rounding in the first place? Most of the time people
want rounded results, they should be reaching for a display format,
not -round()-.
Quite what Stata does internally is naturally a question for StataCorp.
Nick
[email protected]
On 20 January 2014 17:56, Lacy,Michael <[email protected]> wrote:
>
> Greetings,
>
> I'd like to clarify what rounding rules Stata implements. In the
> grand scheme of things, the answer is trivial, but several examples
> have aroused my curiosity. I did find
> http://www.stata.com/statalist/archive/2005-12/msg00403.html
> in the archives, but it doesn't quite fit the current situation.
>
> Background:
> Someone I was helping wondered why I had rounded 4.5 to 4 when rounding to
> the nearest integer. I explained that to my knowledge, banker's rounding,
> i.e., rounding values ending in 5 so that the result ends in an even digit,
> had been the standard for many decades. I discovered later that this
> rule is no longer universally taught, and has been replaced by the biased
> but simpler rule of "always round upward values ending in 5." (Shocking to
> me, but ...) This prompted me to wonder what Stata did. I presumed it
> implemented banker's rounding. The following thus surprised me:
>
> -display round(4.5,1)- = 5 and
> -display round(4.55,0.1) = 4.5
>
> It first occurred to me that this might be a floating point precision
> issue, but I thought not, since 4.5 has an exact binary representation.
> (I also found that the equivalent function call in Excel agrees on the
> first instance but not the second, but that's another matter.)
>
> This prompted me to check out the IEEE rules on rounding, of which the
> recommended default (loosely stated) is to round so as to make the least
> significant bit of the result even, i.e., 0. On this rule round(4.55, 0.1)
> might give 4.5, depending on the place at which the least significant bit
> occurs, but I'm not sure what this rule would mean for round(4.5,1).
> 4.5 would clearly round to 4 (100b vs. 101b) in integer arithmetic,
> but the floating point representations of both 4.0 and 5.0 both end in
> 0, i.e. 100.000 etc. and 101.000 etc., so that leaves me wondering.
>
> I had the thought that Stata's behavior was perhaps documented somewhere, but I
> didn't happen to find it. And, lastly, I could imagine this behavior varying
> from one hardware platform to another, if round() ends up using a hardware call.
>
> So, can someone clarify what rule round() implements?
>
>
> Regards,
>
> Mike Lacy
> Fort Collins CO
> *
> * For searches and help try:
> * http://www.stata.com/help.cgi?search
> * http://www.stata.com/support/faqs/resources/statalist-faq/
> * http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/faqs/resources/statalist-faq/
* http://www.ats.ucla.edu/stat/stata/