Re: st: Error with -round()-

[Nick Cox <njcoxstata@gmail.com>]

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/