Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
From | Nick Cox <njcoxstata@gmail.com> |
To | "statalist@hsphsun2.harvard.edu" <statalist@hsphsun2.harvard.edu> |
Subject | Re: st: Error with -round()- |
Date | Mon, 10 Mar 2014 15:17:35 +0000 |
To underline Jeph's point: This is really the more general solution, as -string()- not only is good for formatting numeric scalars and numeric constants held in local and global macros -- the context for Matt's original question here -- but also is a way to ensure a predictably formatted representation of a numeric variable. There are other benign uses, on which I now digress slightly. A common small problem is arranging for a table-like display but with different roundings for different columns. -tabdisp- for example has a -format()- option but it applies to all numeric variables shown. Showing means and standard deviations to (say) 2 or 3 decimal places can seem about right but it then looks silly that counts appear as 42.000 or similar. The work-around is to put a copy of those integers into a string variable, as -tabdisp- just shows strings exactly as received. The same kind of device can used to produce nice tables through -list-. You just ensure that what look like numeric displays are just string variables derived using appropriate formats. Nick njcoxstata@gmail.com On 10 March 2014 13:51, Jeph Herrin <info@flyingbuttress.net> wrote: > Or, for a solution that will extend to string variables as well: > > local value=string(.8125,"%3.2f") > di "`value'" > > Eg, you can use this to do things like > > gen str4 value=string(var1,"%3.2f") > > when needed. > > hth, > Jeph > > > > > On 3/9/2014 4:26 AM, Nick Cox wrote: >> >> There is no bug here, merely a surprise if you don't understand what >> is going on. In fact, this is probably the most reported bug that is >> just a surprise at first sight in the history of Stata. I'd estimate >> reports on Statalist that are of the order of one hundred over several >> years. >> >> . local value = round(.8125,.01) >> >> . di "`value'" >> .8100000000000001 >> >> . di `value' >> .81 >> >> In the first example, you are seeing the decimal approximation to a >> binary approximation to .81. A little thought shows that .81, although >> a simple decimal, doesn't have an exact binary equivalent, but Stata >> does the best it can. >> >> When you insist on -display- as a string Stata is as literal as it knows. >> >> In the second example, -display-'s role is to display nicely and the >> default numeric format is sufficient to round off the minute detail. >> >> The positive answer, although it may seem paradoxical at first sight, >> is that in Stata rounding of fractions is a string manipulation, not a >> numeric manipulation. (Rounding to integers is safe either way, as >> integers within Stata's limits clearly can be held exactly as binaries >> and as decimals.) >> >> local value : di %3.2f .8125 >> di "`value'" >> >> di "`: di %3.2f .8125" >> >> are ways to ensure the correct result. >> >> For much, much more -search precision- and home in on William Gould's >> blog posts, the manual entries and three Stata Journal papers on this >> subject. >> >> Nick >> njcoxstata@gmail.com >> >> >> On 9 March 2014 02:46, Matt Vivier <mvivier@remedypartners.com> wrote: >>> >>> Hello all, >>> >>> I'm using: >>> Stata/IC 12.1 for Windows (64-bit x86-64) >>> Revision 06 Feb 2012 >>> >>> I'm very hesitant to suggest that there is a bug in Stata itself, but >>> I am getting an unexpected result when using -round()- on some >>> numbers, and have been unable to find an explanation for it. >>> >>> I'm pulling information out of my dataset, and writing it to a table >>> in an HTML file, and wanted to round the values down to something of >>> reasonable length. The vast majority of the time, -round()- functions >>> as expected, but it occasionally seems to misfire. >>> >>> This can be replicated with: >>> local value = round(.8125,.01) >>> di "`value'" >>> >>> However, if you type >>> di `value' >>> >>> You see the expected result. >>> Unfortunately, (I believe) I have to enclose it in quotes to write it >>> to the HTML file as such: >>> file write html `"<TD>`value'</TD>"' >>> >>> My questions are: >>> Can anyone replicate this issue? >>> If so, any thoughts on what causes it? It seems to be caught up in >>> treating `value' like a string due to the quotes. >>> Any thoughts on a workaround? >> >> * >> >> * 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/ * * 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/