Graph displaying too many decimal places

[paulvonhippel]

The graph below is generated by these two lines of code:

format %3.1g rho
line rel_bias M, by(rho)

I thought the format statement would limit the display of rho to one decimal place. As you can see in the graph, however, rho has many decimal places for the last two panels.
What am doing wrong?

[ericmelse]

Dear Paul,

You are not doing anything 'wrong' but Stata reports the original data. In this case you first have to create an new (coded) variable of your rho and used that as your 'byable' variable.
Like:

* Create rounded variable
gen c_rho = round(rho,.1)
* Plot your graph
line rel_bias M, by(c_rho)

Note that the round(varname,.1) implies one decimal and to round to two, three, four etc., decimals you have to add a zero for the next decimal, like:,
round(varname,.01), round(varname,.001), round(varname,.0001) etc.

Should you need to round a particular statistic and include that as an element in any graph, then you can use a local, like:

* get local to report a rounded statistic
gen count=1
qui sum varname
local meantoreport = round(r(mean),.01)
* and use it somewhere
xtitle(varname mean=`meantoreport')

Really useful is to round a particular ratio or percentage that you calculate and include that as an element in any graph, like:

* create a binary to count something in your data
gen count=1
* get local to report a rounded statistic
qui sum count if sex==0
local countedmales = r(N)
qui sum count
local percentagetoreport = round((r(N)/`countedmales')*100,.1)
* and use it somewhere
xtitle(Males in the cohort: `percentagetoreport'%)

Best,
Eric

[Nick Cox]

round() doesn't always work here, as most multiples of 0.1 don't have exact binary equivalents. . I would just try

format %3.1f rho

[paulvonhippel]

Thanks for your suggestions. Unfortunately, neither round(rho,.1) nor "format %3.1f rho" solved the problem here. The code below does both, and the output graph (displayed) still has too many decimal places. What am I doing wrong?

forvalues rho = .1(.1).9 {
 forvalues m = 2(1)100 {
  clear
  local obs = `m'-1
  set obs `obs'
  gen weight = _n
  gen power = `m' - _n
  gen rho = round(`rho',.1)
  gen rho_power = rho^power
  collapse avg_rho_power = rho_power [fweight=weight]
  gen rel_bias = -avg_rho_power
  gen rho = round(`rho',.1)
  gen M = `m'
  if `rho'==.1 & `m'==2 {
   save acf_summary, replace
  }
  else {
   append using acf_summary
   save acf_summary, replace
  }
 }
}

format %3.1f rho
line rel_bias M, by(rho)

[Nick Cox]

A fix to the graphical problem is then just

gen rho2 = string(rho, "%2.1f") 
line rel_bias M, by(rho2, note(Graphs by rho) ) 

.

There are hundreds of file operations here. It can all be done with one file, I guess. Other things are supervening here and now, so let the first person to post show how.

[paulvonhippel]

Your formatting tip worked great, thanks! Are you suggesting that all the collapses, saves, and appends are slowing my program down? I suppose there's a way to do it all with egen.

[Nick Cox]

It looks as if you could just create one file and then use by: and loops to use subsets of the data.

[paulvonhippel]

I'm sure. Would that run faster?

[Nick Cox]

Yes. I think further speed-ups are possible, but this is already faster.

clear 
set obs 891 

local i = 1 

gen rel_bias = . 
gen rho = . 
gen M = . 

quietly forvalues r = 1/9 {
 label def rho `r' "0.`r'", add       
 forvalues m = 2/100 {
  local obs = `m' - 1
  gen weight = _n in 1/`obs'
  gen power = `m' - _n in 1/`obs'
  gen rho_power = (`r'/10)^power
  su rho_power [fweight=weight], meanonly 
  replace rel_bias = -r(mean) in `i' 
  replace rho = `r' in `i'
  replace M = `m' in `i'
  local ++i 
  drop weight power rho_power 
  }
}

label val rho rho 
line rel_bias M, by(rho)

Notice another way to solve the display format problem. See https://www.stata-journal.com/sjpdf....iclenum=pr0051 for the idea of looping over integers whenever you can.

[Nick Cox]

If you lean on -by:- no loops should be necessary at all.

[Nick Cox]

#10 looks more wrong than right. I failed to rewrite it without loops.

But #9 should be correct. The code there is unlikely to be the fastest possible, It's hard to justify spending a lot of time trying to shave a second off what may be a one-off calculation, however.