Rounding/Precision issue in esttab

[HELP PLEASE]

I am currently trying to round up the coefficients and R2 in esttab. I am aiming to round the coefficient to 3 decimal places using b(3) and the R2 to 2 decimal places using r(2). This works fine however, the issue is that this rounding method does not seem to be rounding up correctly. My r2= 0.505 and when I try to use r(2) it rounds to 0.50 and I need it/would expect it, to round to 0.51? similarly, my coefficient = 0.0005, using b(3) surely this should report as 0.001, however, it rounds to 0.000. Any help on to get these to round upwards and not downwards would be greatly appreciated.

[Andrew Musau]

Please note our strong preference for full real names: https://www.statalist.org/forums/help#realnames. Click on “Contact us” located at the bottom right-hand corner of the page and request that your name be changed.

My r2= 0.505 and when I try to use r(2) it rounds to 0.50 and I need it/would expect it, to round to 0.51? similarly, my coefficient = 0.0005, using b(3) surely this should report as 0.001, however, it rounds to 0.000. Any help on to get these to round upwards and not downwards would be greatly appreciated.

Note that estout is from SSC (FAQ Advice #12). You are looking at rounded values to begin with (- with the option b(3)-). If the stored value is between 0.5045 - 0.5049, you have 0.505 rounded to 3 d.p. and 0.50 rounded to 2 d.p.. After the regression, to view the stored value,

regress ...
display e(r2)

Same for the coefficient, where below, replace "varname" with the variable name.

display _b[varname]

[HELP PLEASE]

I appreciate your response, and will be sure to get in touch to change name.

When I perform display e(r2), I get this result:
.50499855

In mathematical theory, the rounded to two decimal places given this value would still = 0.51. Thus, is there anyway to treat this problem and get stata to round up the whole value and not just round from 0.504?.

Thanks

[Nick Cox]

#2 was exactly what I would have written, except that I will add that coefficients of interest deserve 2 significant figures at an absolute minimum. Reporting 0.001 as a coefficient is not informative, as it could mean anything from 0.0005 to almost 3 times that. Very small or very large coefficients are sometimes a sign that units of measurement should be changed.

#3 is surely wrong. That number to 2 decimal places is 0.50.

There are ways to round up and circumstances in which it is right thing to do, but not here.

[HELP PLEASE]

Thanks Nick, I am however, only replicating a table from an article and not conducting any analysis myself, the figures I'm trying to replicate are thus, the ones reported in that which I am trying to replicate.

[Maarten Buis]

0.50499855 rounds to 0.50 not 0.51. When rounding, you look at the next digit (in our case 4) and see if it is larger than or equal to 5. If that is the case than you round up, otherwise you do nothing. 4 is less than 5, so you do nothing and 0.50499855 rounds to 0.50.

[HELP PLEASE]

I understand that, but if we're systematically rounding up from right to left, we would surely arrive at: (0.5049986 -> 0.504999 -> 0.505 -> 0.51) ?

[Andrew Musau]

I understand that, but if we're systematically rounding up from right to left, we would surely arrive at: (0.5049986 -> 0.504999 -> 0.505 -> 0.51) ?

No theory that I know of advocates this. You have one value and you round once if there is need for rounding.

[Nick Cox]

Sorry, but I am lost on why the context in #5 makes any differences to the principles here -- unless the replication is showing that some previous worker fudged their results.

[Maarten Buis]

I understand by that, but if we're systematically rounding up from right to left, we would surely arrive at: (0.5049986 -> 0.504999 -> 0.505 -> 0.51) ?

That is not how rounding works.

Say we want to round 0.49 to the an integer. So we have to choose between 0 and 1. If we choose 0, we make an error of 0.49, and if we choose 1 we make an error of 0.51. We choose the integer with the smallest error, i.e. 0. By looking only at the next digit and ignore all subsequent digits we minimize the error. If you move from right to left you are not guaranteed to minimize the error.

Another way to see why your rule doesn't make sense is to look at what the right most digit is fo a number like pi? Since the digits just keep coming, there would, following your rule, be no way to round pi.